Multi-space trial design platform

ABSTRACT

A method, according to some implementations, includes obtaining a criteria for a trial design study, determining permutations for designs in response to the criteria, and determining permutations for scenarios in response to the criteria. The method may further include generating combinations of the permutations for the designs and the permutations for the scenarios, simulating designs corresponding to the generated combinations, and determining performance of the simulated designs.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority to U.S. ProvisionalPatent Application Ser. No. 62/968,874 (Attorney Docket No.CTYL-0001-P01), filed Jan. 31, 2020, and entitled “CLINICAL TRIAL DESIGNPLATFORM”.

This application also claims the benefit of priority to U.S. ProvisionalPatent Application Ser. No. 63/002,197 (Attorney Docket No.CTYL-0001-P02), filed Mar. 30, 2020, and entitled “CLINICAL TRIAL DESIGNPLATFORM”.

This application also claims the benefit of priority to U.S. ProvisionalPatent Application Ser. No. 63/002,253 (Attorney Docket No.CTYL-0001-P03), filed Mar. 30, 2020, and entitled “CLINICAL TRIAL DESIGNPLATFORM”.

This application also claims the benefit of priority to U.S. ProvisionalPatent Application Ser. No. 63/037,977 (Attorney Docket No.CTYL-0001-P04), filed Jun. 11, 2020, and entitled “CLINICAL TRIAL DESIGNPLATFORM”.

This application also claims the benefit of priority to U.S. ProvisionalPatent Application Ser. No. 63/085,700 (Attorney Docket No.CYTL-0001-P05), filed Sep. 30, 2020, and entitled “CLINICAL TRIAL DESIGNPLATFORM”.

This application also claims the benefit of priority to U.S. ProvisionalPatent Application Ser. No. 63/086,474 (Attorney Docket No.CYTL-0001-P06), filed Oct. 1, 2020, and entitled “CLINICAL TRIAL DESIGNPLATFORM”.

Each of the foregoing applications is incorporated herein by referencein its entirety.

SUMMARY

The success and the performance of a clinical trial depends on thedesign of the trial. Different choices for the design of a trial mayresult in very different costs, completion times, and/or otherperformance parameters for the trial. A trial design platform, systems,and methods are described herein for evaluation and/or comparison ofdesigns for a clinical trial. Evaluation and/or comparison may include alarge number of design options. Embodiments of the current disclosuremay be used to evaluate hundreds, thousands, or even millions of designoptions for a clinical trial and may be used to find the optimal ornear-optimal design for a trial.

The success of the clinical trial often depends on the ability torecruit a satisfactory number of patients, suitable to participate inthe clinical trial. The number of suitable patients available to berecruited for a clinical trial is, in turn, typically a function of thesites selected for the clinical trial. The selection of sites for aclinical trial may include considerations and tradeoffs between hundredsor even thousands of site selections. Embodiments of the currentdisclosure may provide for a site selection platform, systems, andmethods for evaluation and/or comparison of site selection options for aclinical trial.

The success of the clinical trial often depends on the availability ofresources needed to conduct the clinical trial. The selection of sitesfor a clinical trial, with respect to optimizing available resources,may include considerations and tradeoffs between hundreds or eventhousands of site selections. Embodiments of the current disclosure mayprovide for a resource optimization platform, systems, and methods forevaluation and/or comparison of site selection options with respect tooptimizing resource availability for a clinical trial. In embodiments,the platform, systems, and methods described herein may be used toevaluate hundreds, thousands, or even millions of site selection optionsfor a clinical trial and may be used to find the optimal or near-optimalresource availability for a trial.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a block diagram of a platform for providing globaloptimization of clinical trial designs, in accordance with an embodimentof the current disclosure;

FIG. 2 is a diagram of a process for globally optimizing clinical trialdesigns, in accordance with an embodiment of the current disclosure;

FIG. 3 is a schematic diagram of an apparatus for determining globallyoptimum designs, in accordance with an embodiment of the currentdisclosure;

FIG. 4 is a schematic diagram of an apparatus for determining globallyoptimum designs, in accordance with an embodiment of the currentdisclosure;

FIG. 5 is a flow chart depicting a method for determining globallyoptimum designs, in accordance with an embodiment of the currentdisclosure;

FIG. 6 is a flow chart depicting a method for determining globallyoptimum designs, in accordance with an embodiment of the currentdisclosure;

FIG. 7 is a flow chart depicting a method for determining globallyoptimum designs, in accordance with an embodiment of the currentdisclosure;

FIG. 8 is a schematic diagram of an apparatus for evaluating designs, inaccordance with an embodiment of the current disclosure;

FIG. 9 is a flow chart depicting a method of evaluating designs, inaccordance with an embodiment of the current disclosure;

FIG. 10 is a flow chart depicting a method of evaluating design, inaccordance with an embodiment of the current disclosure;

FIG. 11 is a schematic diagram of an apparatus for evaluating designs,in accordance with an embodiment of the current disclosure;

FIG. 12 is a block diagram of an interface for configuring and managingan execution flow for a clinical trial design evaluation, in accordancewith an embodiment of the current disclosure;

FIG. 13 is a schematic diagram of another embodiment of an interface forconfiguring and managing an execution flow for a clinical trial designevaluation, in accordance with an embodiment of the current disclosure;

FIG. 14 is a block diagram of two distinct views of the interface ofFIG. 12, in accordance with an embodiment of the current disclosure;

FIG. 15 is a diagram of user types corresponding to the views of FIG.14, in accordance with an embodiment of the current disclosure;

FIG. 16 is a flow chart depicting a method for configuring and managingan execution flow for a clinical trial design evaluation, in accordancewith an embodiment of the current disclosure;

FIG. 17 is a flow chart depicting another method for configuring andmanaging an execution flow for a clinical trial design evaluation, inaccordance with an embodiment of the current disclosure;

FIG. 18 is a schematic diagram of an apparatus for configuring andmanaging an execution flow for a clinical trial design evaluation, inaccordance with an embodiment of the current disclosure;

FIG. 19 is a schematic diagram of an interactive interface for anadvisor for guiding a user through configuration of trial designsimulations and/or systems for optimizing clinical trial design, inaccordance with an embodiment of the current disclosure;

FIG. 20 is a schematic diagram of another embodiment of the interactiveinterface of FIG. 19, in accordance with an embodiment of the currentdisclosure;

FIG. 21 is a schematic diagram of a prompt of the interactive interfaceof FIG. 19, in accordance with an embodiment of the current disclosure;

FIG. 22 is a block diagram depicting stages of configuring a clinicaltrial design optimization process, in accordance with an embodiment ofthe current disclosure;

FIG. 23 is flow chart depicting a method for guiding a user throughconfiguration of trial design simulations and/or systems for optimizingclinical trial design, in accordance with an embodiment of the currentdisclosure;

FIG. 24 is a flow chart depicting another embodiment of the method ofFIG. 23, in accordance with an embodiment of the current disclosure;

FIG. 25 is a block diagram of an apparatus for guiding a user throughconfiguration of trial design simulations and/or systems for optimizingclinical trial design, in accordance with an embodiment of the currentdisclosure;

FIG. 26 is a flow chart depicting a method for augmenting simulateddata, in accordance with an embodiment of the current disclosure;

FIG. 27 is a schematic diagram of an apparatus for augmenting simulateddata, in accordance with an embodiment of the current disclosure;

FIG. 28 is a is a flow chart for evaluating designs, in accordance withan embodiment of the current disclosure;

FIG. 29 is a flow chart depicting a method for evaluating designs, inaccordance with an embodiment of the current disclosure;

FIG. 30 is a flow chart showing aspects of utilizing virtualpopulations, in accordance with an embodiment of the current disclosure;

FIG. 31 is a flow chart for utilizing virtual populations andcounterfactual data, in accordance with an embodiment of the currentdisclosure;

FIG. 32 is a flow chart depicting a method for evaluating designs withcounterfactual data, in accordance with an embodiment of the currentdisclosure;

FIG. 33 is a flow chart depicting a method for evaluating designs withcounterfactual data, in accordance with an embodiment of the currentdisclosure;

FIG. 34 is a schematic depicting a circuit for evaluating designs withcounterfactual data, in accordance with an embodiment of the currentdisclosure;

FIG. 35 is a is a schematic diagram of an apparatus for determiningdesigns from user interactions, in accordance with an embodiment of thecurrent disclosure;

FIG. 36 is a is a schematic diagram of an apparatus for determiningdesigns from user interactions, in accordance with an embodiment of thecurrent disclosure;

FIG. 37 is a flow chart depicting a method for determining designs fromuser interactions, in accordance with an embodiment of the currentdisclosure;

FIG. 38 is a flow chart depicting a method for determining designs fromuser interactions, in accordance with an embodiment of the currentdisclosure;

FIG. 39 shows aspects of a card interface, in accordance with anembodiment of the current disclosure;

FIG. 40 is a flow chart depicting a method for design analysis using acard interface, in accordance with an embodiment of the currentdisclosure;

FIG. 41 is a schematic diagram of an apparatus for design analysis usinga card interface, in accordance with an embodiment of the currentdisclosure;

FIG. 42 is a schematic diagram of an apparatus for design analysis usinga card interface, in accordance with an embodiment of the currentdisclosure;

FIG. 43 shows aspects of a tornado interface, in accordance with anembodiment of the current disclosure;

FIG. 44 shows aspects of a heatmap interface, in accordance with anembodiment of the current disclosure;

FIG. 45 is a schematic diagram of an embodiment of the platform 104having a primary algorithm, in accordance with the current disclosure;

FIG. 46 is a flow chart depicting a workflow of the primary algorithm ofFIG. 45, in accordance with an embodiment of the current disclosure;

FIG. 47 is a schematic diagram of an apparatus that implements theprimary algorithm of FIG. 45, in accordance with an embodiment of thecurrent disclosure;

FIG. 48 is a graph showing aspects of Pareto analysis in accordance withan embodiment of the current disclosure;

FIG. 49 is a table showing aspects of Pareto analysis in accordance withan embodiment of the current disclosure;

FIG. 50 is a schematic diagram of an apparatus for determining optimumdesigns using Pareto analysis, in accordance with an embodiment of thecurrent disclosure;

FIG. 51 is a is a schematic diagram of an apparatus for determiningoptimum designs using Pareto analysis, in accordance with an embodimentof the current disclosure;

FIG. 52 is a flow chart depicting a method for determining globallyoptimum designs with Pareto analysis, in accordance with an embodimentof the current disclosure;

FIG. 53 is a flow chart depicting a method for determining globallyoptimum designs with Pareto analysis, in accordance with an embodimentof the current disclosure;

FIG. 54 depicts aspects of convex hull (CH) analysis in accordance withan embodiment of the current disclosure;

FIG. 55 depicts aspects of convex hull analysis in accordance with anembodiment of the current disclosure;

FIG. 56 is a is a schematic diagram of an apparatus for determiningoptimum designs using convex hull analysis, in accordance with anembodiment of the current disclosure;

FIG. 57 is a is a schematic diagram of an apparatus for determiningoptimum designs using convex hull analysis, in accordance with anembodiment of the current disclosure;

FIG. 58 is a flow chart depicting a method for determining globallyoptimum designs with convex hull analysis, in accordance with anembodiment of the current disclosure;

FIG. 59 is a flow chart depicting a method for determining globallyoptimum designs with convex hull analysis, in accordance with anembodiment of the current disclosure;

FIG. 60 shows aspects of robustness analysis in accordance with anembodiment of the current disclosure;

FIG. 61 shows aspects of robustness analysis in accordance with anembodiment of the current disclosure;

FIG. 62 is a schematic diagram of an apparatus for determiningrobustness of designs, in accordance with an embodiment of the currentdisclosure;

FIG. 63 is a flow chart depicting a method for determining robustness ofdesigns, in accordance with an embodiment of the current disclosure;

FIG. 64 is a flow chart depicting a method for determining robustness ofdesigns, in accordance with an embodiment of the current disclosure;

FIG. 65 is a is a schematic diagram of an apparatus for evaluatingdesign with simulated annealing, in accordance with an embodiment of thecurrent disclosure;

FIG. 66 is a is a flow chart evaluating design with simulated annealing,in accordance with an embodiment of the current disclosure;

FIG. 67 is a flow chart depicting a method for evaluating a design withsimulated annealing, in accordance with an embodiment of the currentdisclosure;

FIG. 68 is a flow chart depicting a method for evaluating a design withsimulated annealing, in accordance with an embodiment of the currentdisclosure;

FIG. 69 is a flow chart depicting a method of simulating clinical trialdesigns based in part on a Delaunay interpolation, in accordance with anembodiment of the current disclosure;

FIG. 70 is a schematic diagram of an apparatus for implementing themethod of FIG. 69, in accordance with an embodiment of the currentdisclosure;

FIG. 71 is a schematic diagram of a recommendation component forrecommending clinical trial designs, in accordance with an embodiment ofthe current disclosure;

FIG. 72 is a schematic diagram of a recommendation engine, in accordancewith an embodiment of the current disclosure;

FIG. 73 is a diagram depicting a relationship between sets of clinicaltrial designs, Pareto designs, convex hull designs, and recommendeddesigns, in accordance with an embodiment of the current disclosure;

FIG. 74 is another diagram of the recommendation engine of FIG. 72, inaccordance with an embodiment of the current disclosure;

FIG. 75 is a diagram of a set of recommended clinical trial designs, inaccordance with an embodiment of the current disclosure;

FIG. 76 is a diagram of a visualization of recommended clinical trialdesigns, in accordance with an embodiment of the current disclosure;

FIG. 77 is a diagram of another visualization of recommended clinicaltrial designs, in accordance with an embodiment of the currentdisclosure;

FIG. 78 is a flow chart depicting an embodiment of a method ofrecommending clinical trial designs, in accordance with the currentdisclosure;

FIG. 79 is a flow chart depicting another embodiment of the method ofFIG. 78, in accordance with the current disclosure;

FIG. 80 is a flow chart depicting another embodiment of the method ofFIG. 78, in accordance with the current disclosure;

FIG. 81 is a schematic diagram of an apparatus for implementing themethod of FIG. 78;

FIG. 82 is a diagram of a simulation queue, in accordance with anembodiment of the current disclosure;

FIG. 83 is a flow chart depicting a method for management andoptimization of clinical trial designs, in accordance with an embodimentof the current disclosure;

FIG. 84 is a schematic diagram of an apparatus for management andoptimization of clinical trial designs, in accordance with an embodimentof the current disclosure;

FIG. 85 is a block diagram of a simulation engine marketplace, inaccordance with an embodiment of the current disclosure;

FIG. 86 is a block diagram of a simulation engine, in accordance with anembodiment of the current disclosure;

FIG. 87 is a diagram of an interface with fields populated based atleast in part on a header section of a simulation engine in accordancewith an embodiment of the current disclosure;

FIG. 88 is a flow chart depicting a method for using a simulationmarketplace in accordance with an embodiment of the current disclosure;

FIG. 89 is a flow chart depicting another method for using a simulationmarketplace in accordance with an embodiment of the current disclosure;

FIG. 90 is a schematic diagram of an apparatus for using a simulationmarketplace in accordance with an embodiment of the current disclosure;

FIG. 91 is a diagram for a process for benchmarking and/or normalizingsimulation engines, in accordance with an embodiment of the currentdisclosure;

FIG. 92 is a flow chart depicting a method for benchmarking and/ornormalizing simulation engines, in accordance with an embodiment of thecurrent disclosure;

FIG. 93 is a schematic diagram of an apparatus for benchmarking and/ornormalizing simulation engines, in accordance with an embodiment of thecurrent disclosure;

FIG. 94 is a block diagram of a plurality of clinical trials andcorresponding clinical trial designs for optimization, in accordancewith an embodiment of the current disclosure;

FIG. 95 is a block diagram of a permutation set of the clinical trialdesigns of FIG. 94 and corresponding combined performance criteria, inaccordance with an embodiment of the current disclosure;

FIG. 96 is a flow chart depicting a method for optimization of clinicaltrial designs across a plurality of clinical trials, in accordance withan embodiment of the current disclosure;

FIG. 97 is a flow chart depicting another embodiment of the method ofFIG. 96, in accordance with the current disclosure;

FIG. 98 is a schematic diagram of an apparatus for optimization ofclinical trial designs across a plurality of clinical trials, inaccordance with an embodiment of the current disclosure.

FIG. 99 is a flow chart depicting a method for determining robustness ofa clinical trial design, in accordance with an embodiment of the currentdisclosure;

FIG. 100 is a flow chart depicting another method for determiningrobustness of a clinical trial design, in accordance with an embodimentof the current disclosure;

FIG. 101 is a schematic diagram of an apparatus for determining arobustness of a clinical trial design, in accordance with an embodimentof the current disclosure;

FIG. 102 is a flow chart depicting a method for updating a clinicaltrial, in accordance with an embodiment of the current disclosure;

FIG. 103 is a flow chart depicting another method for updating aclinical trial, in accordance with an embodiment of the currentdisclosure;

FIG. 104 is a block diagram of a platform for providing globaloptimization of site selection for clinical trial designs, in accordancewith an embodiment of the current disclosure;

FIG. 105 is a diagram of a process for globally optimizing siteselection for clinical trial designs, in accordance with an embodimentof the current disclosure;

FIG. 106 is a schematic diagram of an apparatus for determining a siteselection to globally optimize patient recruitment for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 107 is a schematic diagram of another apparatus for determining asite selection to globally optimize patient recruitment for a clinicaltrial, in accordance with an embodiment of the current disclosure;

FIG. 108 is a flow chart depicting a method for determining a siteselection to globally optimize patient recruitment for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 109 is a flow chart depicting another method for determining a siteselection to globally optimize patient recruitment for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 110 is a flow chart depicting another method for determining a siteselection to globally optimize patient recruitment for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 111 is a flow chart depicting another method for determining a siteselection to globally optimize patient recruitment for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 112 is a flow chart depicting an apparatus for determining a siteselection to globally optimize patient recruitment for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 113 is a diagram of a platform with an interface for collaborativeconfiguration of a site selection for optimization of patientrecruitment for a clinical trial, in accordance with an embodiment ofthe current disclosure;

FIG. 114 is a flow chart depicting a method for collaborativeconfiguration of a site selection for optimization of patientrecruitment for a clinical trial, in accordance with an embodiment ofthe current disclosure;

FIG. 115 is a schematic diagram of an apparatus for collaborativeconfiguration of a site selection for optimization of patientrecruitment for a clinical trial, in accordance with an embodiment ofthe current disclosure;

FIG. 116 is a flow chart depicting another method for collaborativeconfiguration of a site selection for optimization of patientrecruitment for a clinical trial, in accordance with an embodiment ofthe current disclosure;

FIG. 117 is a diagram of a platform for configuring a system forglobally optimizing patient recruitment for a clinical trial, inaccordance with an embodiment of the current disclosure;

FIG. 118 is a flow chart depicting a method for predicting an initialsite selection with respect to patient recruitment for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 119 is a schematic diagram of an apparatus for predicting aninitial site selection with respect to patient recruitment for aclinical trial, in accordance with an embodiment of the currentdisclosure;

FIG. 120 is a diagram of a platform/system for generating an interactiveinterface for exploration/evaluation of spaces related to patientrecruitment for a clinical trial, in accordance with an embodiment ofthe current disclosure;

FIG. 121 is a flow chart depicting a method for generating aninteractive interface for exploration/evaluation of spaces related topatient recruitment for a clinical trial, in accordance with anembodiment of the current disclosure;

FIG. 122 is a schematic diagram of an apparatus for generating aninteractive interface for exploration/evaluation of spaces related topatient recruitment for a clinical trial, in accordance with anembodiment of the current disclosure;

FIG. 123 is a flow chart depicting a method for updating patientrecruitment, in accordance with an embodiment of the current disclosure;

FIG. 124 is a flow chart depicting another method for updating patientrecruitment, in accordance with an embodiment of the current disclosure;

FIG. 125 is a block diagram of a platform for providing globaloptimization of resource availability for clinical trial designs, inaccordance with an embodiment of the current disclosure;

FIG. 126 is a diagram of a process for globally optimizing resourceavailability for clinical trial designs, in accordance with anembodiment of the current disclosure;

FIG. 127 is a schematic diagram of an apparatus for determining a siteselection to globally optimize available resources for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 128 is a schematic diagram of another apparatus for determining asite selection to globally optimize available resources for a clinicaltrial, in accordance with an embodiment of the current disclosure;

FIG. 129 is a flow chart depicting a method for determining a siteselection to globally optimize available resources for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 130 is a flow chart depicting another method for determining a siteselection to globally optimize available resources for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 131 is a flow chart depicting another method for determining a siteselection to globally optimize available resources for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 132 is a flow chart depicting another method for determining a siteselection to globally optimize available resources for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 133 is a flow chart depicting an apparatus for determining a siteselection to globally optimize available resources for a clinical trial,in accordance with an embodiment of the current disclosure;

FIG. 134 is a diagram of a platform with an interface for collaborativeconfiguration of a site selection for optimization of availability ofresources for a clinical trial, in accordance with an embodiment of thecurrent disclosure;

FIG. 135 is a flow chart depicting a method for collaborativeconfiguration of a site selection for optimization of availability ofresources for a clinical trial, in accordance with an embodiment of thecurrent disclosure;

FIG. 136 is a schematic diagram of an apparatus for collaborativeconfiguration of a site selection for optimization of availability ofresources for a clinical trial, in accordance with an embodiment of thecurrent disclosure;

FIG. 137 is a flow chart depicting another method for collaborativeconfiguration of a site selection for optimization of availability ofresources for a clinical trial, in accordance with an embodiment of thecurrent disclosure;

FIG. 138 is a diagram of a platform for configuring a system forglobally optimizing availability of resources for a clinical trial, inaccordance with an embodiment of the current disclosure;

FIG. 139 is a flow chart depicting a method for predicting an initialsite selection with respect to optimizing available resources for aclinical trial, in accordance with an embodiment of the currentdisclosure;

FIG. 140 is a schematic diagram of an apparatus for predicting aninitial site selection with respect to available resources for aclinical trial, in accordance with an embodiment of the currentdisclosure;

FIG. 141 is a diagram of a platform/system for generating an interactiveinterface for exploration/evaluation of spaces related to availabilityof resources for a clinical trial, in accordance with an embodiment ofthe current disclosure;

FIG. 142 is a flow chart depicting a method for generating aninteractive interface for exploration/evaluation of spaces related toavailability of resources for a clinical trial, in accordance with anembodiment of the current disclosure;

FIG. 143 is a schematic diagram of an apparatus for generating aninteractive interface for exploration/evaluation of spaces related toavailability of resources for a clinical trial, in accordance with anembodiment of the current disclosure;

FIG. 144 is a flow chart depicting a method for updating site selectionaccording to available resources, in accordance with an embodiment ofthe current disclosure;

FIG. 145 is a flow chart depicting another method for updating siteselection according to available resources, in accordance with anembodiment of the current disclosure;

FIG. 146 depicts aspects of a view of an organization of a platform, inaccordance with an embodiment of the current disclosure;

FIG. 147 is a schematic diagram of a system for efficient resourceallocation in accordance with an embodiment of the current disclosure;

FIG. 148 is a flow chart depicting a method for efficient resourceallocation in accordance with an embodiment of the current disclosure;

FIG. 149 is a schematic diagram of a system for determining a score inaccordance with an embodiment of the current disclosure;

FIG. 150 is a flow chart depicting a method for determining a score, inaccordance with an embodiment of the current disclosure;

FIG. 151 is a flow chart depicting a method for score transformation, inaccordance with an embodiment of the current disclosure;

FIG. 152 is a flow chart depicting a method for determining acollaborative session sequence, in accordance with an embodiment of thecurrent disclosure;

FIG. 153 is a flow chart depicting a method for generating acollaborative interface, in accordance with an embodiment of the currentdisclosure;

FIG. 154 is a schematic diagram of a system for generating acollaborative interface in accordance with an embodiment of the currentdisclosure;

FIG. 155 is a diagram of a hierarchy of convex hulls in accordance withan embodiment of the current disclosure;

FIG. 156 is a flow chart depicting a method determining a designhierarchy based on convex hull peeling, in accordance with an embodimentof the current disclosure;

FIG. 157(a-e) is a diagram depicting a method for determining a convexhull for a scenario, in accordance with an embodiment of the currentdisclosure;

FIG. 158 is a flow chart depicting a method for determining a scenarioconvex hull, in accordance with an embodiment of the current disclosure;

FIG. 159 is a diagram depicting an apparatus for convex hull peeling, inaccordance with an embodiment of the current disclosure;

FIG. 160 is a schematic diagram of a system for providing adaptivereplication in clinical trial design simulation, in accordance with anembodiment of the current disclosure;

FIG. 161 is a schematic diagram for an apparatus for providing adaptivereplication in clinical trial design simulation, in accordance with anembodiment of the current disclosure;

FIG. 162 is a flow chart depicting a method for providing adaptivereplication in clinical trial design simulation, in accordance with anembodiment of the current disclosure;

FIG. 163 is a schematic diagram of a system for providing enhancedsimulated annealing, in accordance with an embodiment of the currentdisclosure;

FIG. 164 is a schematic diagram of an apparatus for providing enhancedsimulated annealing, in accordance with an embodiment of the currentdisclosure;

FIG. 165 is a diagram of a design space having neighboring clinicaltrial designs, in accordance with an embodiment of the currentdisclosure;

FIG. 166 is a diagram of a convex hull tunnel, in accordance with anembodiment of the current disclosure;

FIG. 167 is a flow chart depicting a method for providing enhancedsimulated annealing, in accordance with an embodiment of the currentdisclosure;

FIG. 168 is a flow chart depicting another method for providing enhancedsimulated annealing, in accordance with an embodiment of the currentdisclosure;

FIG. 169 is a flow chart depicting yet another method for providingenhanced simulated annealing, in accordance with an embodiment of thecurrent disclosure;

FIG. 170 is a schematic diagram of a system for design exploration andsearch, in accordance with an embodiment of the current disclosure;

FIGS. 171(a-b) are diagrams of a quick search data structure, inaccordance with an embodiment of the current disclosure;

FIG. 172 is a flow chart depicting a method for design exploration andsearch, in accordance with an embodiment of the current disclosure;

FIG. 173 is a flow chart of another method for design exploration andsearch, in accordance with an embodiment of the current disclosure;

FIG. 174 is a flow chart depicting another method for design explorationand search, in accordance with an embodiment of the current disclosure;

FIG. 175 is a flow chart depicting another method for design explorationand search, in accordance with an embodiment of the current disclosure;

FIG. 176 is a diagram of an interface for design exploration and search,in accordance with an embodiment of the current disclosure;

FIG. 177 is flow chart depicting another method for design explorationand search, in accordance with an embodiment of the current disclosure;

FIG. 178 is flow chart depicting another method for design explorationand search, in accordance with an embodiment of the current disclosure;

FIG. 179 is flow chart depicting another method for design explorationand search, in accordance with an embodiment of the current disclosure;

FIG. 180 is a diagram of a design space, in accordance with anembodiment of the current disclosure; and

FIGS. 181(a-k) are diagrams of an example project, in accordance with anembodiment of the current disclosure.

DETAILED DESCRIPTION

Clinical trials (herein, also referred to as a “trial” or “study”) maybe used to assess, examine and evaluate drugs, devices, procedures,treatments, therapies, and the like. Clinical trials may be used toevaluate the efficiency, performance, and/or effectiveness of treatmentsfor subjects. Embodiments of the current disclosure may also optimizefor clinical trial resources, which may include drugs/drug supplysubject to the trial, devices subject to the trial, administrativepersonnel, and/or equipment needed to administer a procedure/drug/devicesubject to the trial.

The success and the performance of a clinical trial depends on thedesign of the trial. In some cases, a wrong choice in the design of atrial may reduce the usefulness of the trial even if the trial isexecuted without error. In some cases, different choices for the designof a trial may result in very different costs, completion times, and/orother performance parameters for the trial.

The design of clinical trials may include considerations and tradeoffsbetween hundreds or even thousands of design options. Traditionally, thedesign of trials has been based on heuristics and experiencedprofessionals to determine which set of parameters will result in adesign that is likely to produce a successful trial. However,traditional approaches are not capable of evaluating more than a handfulof design options and tradeoffs and may often miss design options thatmay result in better performance. The cost of a clinical trial may oftenexceed tens of millions or even hundreds of millions of dollars and maytake years to complete, thus, small differences in the performance of atrial design may result in large impacts on the overall cost and timeassociated with corresponding trials.

The complexity of a trial design often requires aspects of statisticalexpertise, clinical design expertise, and software expertise, which maynot be available in many organizations. As such, many organizationsfallback on the use of generic study designs due to their inability tofind optimal or near-optimal study designs.

A trial design platform, systems, and methods are described herein forevaluation and/or comparison of designs for a clinical trial. Inembodiments, evaluation and/or comparison may include a large number ofdesign options. In some embodiments, the platform, systems, and methodsdescribed herein may be used to evaluate hundreds, thousands, or evenmillions of design options for a clinical trial and may be used to findthe optimal or near-optimal design for a trial.

The trial design platform may be used for trial design. In embodiments,a trial design platform may support a team in collaborating andsurfacing all the inputs that are key to consider for preparing andselecting an optimal design. The trial design platform may use cloud anddistributed computing so the team can simulate hundreds of millions ofstudy design variants across all those inputs. The trial design platformmay present the team with prioritized options and visualizations toenable the interrogation of the drivers of value. As used herein, a“team” may include a single individual or a group of individuals.Embodiments of the platforms disclosed herein may provide forcollaboration within a single organization and/or across multipleorganizations. In embodiments, an organization may be a business entityand/or a regulation authority, e.g., a governmental agency, and/or otherentity charged with oversight and/or certification of clinical trials.

A trial design platform may enable a team to quickly identify optimaldesigns and the factors that most strongly drive performance factors,strategic goals, and the like. A trial design platform, as describedherein, may leverage emerging technologies to provide options foradvanced simulations, distributed computing, visualizations, and thelike. The trial design platform may leverage methodological knowledge,analysis of the business value of different design choices, and/oranalysis of regulatory risk and operational complexity to determineoptimum or near optimum study designs. The trial optimization platformmay determine optimum or near optimum study designs by leveraging anovel workflow, speed and/or computing innovations, and/or powerfulvisualizations for study analysis and optimization.

A trial design platform may improve how data and processes are used tomake better decisions on clinical trial design. Improvements may resultfrom recognizing which innovative designs might significantly increasegoals. Improvements may be obtained by communicating the benefits ofspecific trial designs in a way that that intuitively allows a varietyof team members to understand the design of a trial and/or possibleoptions for the design of the trial. A trial design platform may supporta team in collaborating and surfacing all the inputs that are key toconsider for preparing and selecting an optimal design. The trial designplatform may present the team with prioritized options and insightfulvisualizations to enable interrogation of the drivers of value.

FIG. 1 shows an embodiment of a platform for evaluation and comparisonof trial designs for treatments for subjects. As used herein, treatmentsmay include procedures, diagnostic tests, devices, diets, placebos,drugs, vaccines, and the like. Treatments may include combinations ofdrugs, devices, procedures and/or therapies. References to subjectsthroughout this disclosure should also be understood to be references topeople, animals, plants, organisms and other living elements.

The platform 104 may provide for a system for providing users withfacilities and methods for designing, evaluating, and/or comparingdesigns. The facilities described herein may be deployed in part or inwhole through a machine that executes computer software, modules,program codes, and/or instructions on one or more processors, asdescribed herein, which may be part of or external to the platform 104.Users may utilize the platform 104 to identify trial designs forcriteria, evaluate the designs, compare designs, determine optimaldesigns, and the like.

A user may interact with the platform 104 through one or more userdevices 102 (e.g., computer, laptop computer, mobile computing device,and the like). The platform 104 may be implemented and/or leverage oneor more computing resources 150 such as a cloud computing service 152,servers 154, software as a service (SaaS), infrastructure as a service(IaaS), platform as a service (PaaS), desktop as a Service (DaaS),managed software as a service (MSaaS), mobile backend as a service(MBaaS), information technology management as a service (ITMaaS), andthe like. The platform 104 may be provided or licensed on a subscriptionbasis and centrally hosted (e.g., accessed by users using a client (forexample, a thin client) via a web browser or other application, accessedthrough or by mobile devices, and the like). In embodiments, elements ofthe platform 104 may be implemented to operate on various platforms andoperating systems. In embodiments, interfaces for the user device 102through which the users may interact with the platform may be served tothe user device 102 through a webpage provided by a server of theplatform 104, an application, and the like.

The platform 104 may include one or more facilities such as aconfiguration facility 106, simulation facility 110, analysis facility108, interfaces facility 112, data facility 138, and computationresources 150.

The configuration facility 106 may include advisors 114, which mayinclude one or more wizards, tools, algorithms, recommenders,configuration elements, questioners, and the like. Advisors may be usedto receive data and/or define or develop space definitions 116. Spacedefinitions 116 may include aspects of criteria space. As used herein,criteria space may include the set of parameters and values of theparameters that define goals for a design. Criteria space may defineinitial parameters for narrowing the design space before optimization.Parameters may include goals of designs, endpoints, primary objectives,secondary objectives, and the like. Criteria space may define values,ranges of values, types, ranges of types, and the like that may definegeneral characteristics of a trial design.

Space definitions 116 may include aspects of design space. As usedherein, design space may include the set of parameters and values of theparameters that define different options and variations of designs.Parameters may include design type, dose of drug, frequency of drug,maximum duration, patient inclusion/exclusion criteria, randomizationtype, and the like. The design space may include all possiblepermutations of the parameters. For example, one design type may beconfigured with different doses of a drug and different frequency of theadministration of the drug. The design space may include all possiblepermutations of the different doses of the drug for all the differentfrequencies of the administration of the drug. The design space mayinclude all the permutations of all the parameters associated withdesign. The design space may include millions of possible designvariations. A trial design platform may evaluate all permutations ofparameters of the design space. A trial design platform may evaluate apartial set of permutations of parameters of the design space. Thepartial set of permutations may be defined by a user. The partial set ofpermutations may be automatically defined, such as according to thecriteria parameters.

Space definitions 116 may include aspects of scenario space. As usedherein, scenario space may include the set of parameters and values ofthe parameters that define different options and variations of scenariosassociated with designs. Scenario space may define the parameters of theenvironment associated with a design. Parameters may include populationenrollment rate, dropout rate, population statistics, and the like. Thescenario space may include all possible permutations of the parameters.For example, one scenario may be configured with a range of values forpopulation enrollment rate and a range of values for patient dropoutrate. The scenario space includes all possible permutations of thepopulation enrollment rate and the patient dropout rate. The scenariospace may include all the permutations of all the parameters associatedwith scenarios. The scenario space may include millions of possiblescenario variations. A trial design platform may evaluate allpermutations of parameters of the scenario space. A trial designplatform may evaluate a partial set of permutations of parameters of thescenario space. The partial set of permutations may be defined by auser. The partial set of permutations may be automatically orsemi-automatically defined, such as according to the criteriaparameters.

Space definitions 116 may include aspects of performance space. As usedherein, performance space may include the set of parameters and valuesof the parameters that define the evaluation criteria for a design.Parameters may include: net present value (NPV), expected NPV,incremental NPV, study cost, incremental study cost, study budget,incremental study budget, time to complete, incremental time tocomplete, time to market, incremental time to market, clinical utility,incremental clinical utility, probability of regulatory acceptance,incremental probability of regulatory acceptance, probability ofsuccess, incremental probability of success, statistical power,incremental statistical power, number of patients, incremental number ofpatients, number of sites, incremental number of sites, studycomplexity, incremental study complexity, operational complexity,incremental operational complexity, dose selected, incremental doseselected, statistical design, incremental statistical design, peakrevenue, revenue at year five (5), other revenue numbers, incrementalrevenue, market introduction, whether market introduction beatscompetition entry, number of treatment arms, hypothesissuperiority/equivalence/non-inferiority, other choices aroundstatistical design, treatment effect, hazard ratio, and other choicesaround estimating the characteristics of the patient population,response, and safety profile, screening criteria, dropout rate, andother choices around modeling/estimating the characteristics andbehaviors of the patient population and other factors that impact howthe study evolves and its likelihood of achieving its goals (howslowly/quickly patients enroll, etc.), site payments and other choicesaround operational aspects of the study that can impact how the studyevolves and its likelihood of achieving its goals, cost per patient,cost per site, or other cost factors, selections made in other projects(across users within customer companies or organizations and across allusers of the platform), priorities set by the customer company ororganization, and/or other user-defined filters based on availableinputs and outputs of the platform or in the systems and methodsdescribed herein. In embodiments, any of the parameters and variablesdescribed herein may be incremental parameters and variables. Designsmay be evaluated and compared against all of the parameters of theperformance space or a subset of the parameters of the performancespace. A set of designs may be evaluated for one or more of theperformance parameters. The performance parameters and the values of theperformance parameters of designs define the performance space of theset of designs.

The configuration facility 106 may include a combinations component 118.The combinations component 118 may automatically or semi-automaticallydefine the design space and/or scenario space that may be evaluated bythe platform.

The simulation facility 110 of the platform 104 may, based on the spacedefinitions from the configuration facility 106, evaluate the trialdesigns. The simulation facility 110 may include models 126. As usedherein, a model includes the combination of parameters and the valuesthat describe a design and the scenario under which the design isevaluated. Models 126 may include hundreds or even thousands of models.Models 126 may include deviation specifications for one or more of theparameters of the models. Deviation specification may define a range ofvalues, a distribution of values, and/or a function of values for one ormore parameters of a model. The deviation specifications may be based onexpected or previously measured distributions or variations in designparameters.

The simulation facility 110 may include engines 128. As used herein,engines may relate to the codification of a design that can receivemodel parameters and run a simulation to generate an output. The outputof the engines 128 may be a predicted behavior for a design for one ormore scenarios and/or conditions. Engines 128 may evaluate a design withanalytical methods, mathematical methods, numerical methods, simulation,and/or the like. As used herein, simulation refers to the execution of amodel using an engine. A simulation may be a single execution of model(one simulation instance) or a simulation run that includes more thanone simulation instance. Evaluating a design may include a simulationrun to determine performance of the design. Evaluating a design mayinclude using a Monte Carlo approach to simulate a design for differentvalues according to the deviation specifications and using statisticalmethods to determine the performance of the design from a simulationrun.

The simulation facility 110 may include search/exploration component130. The search/exploration component may facilitate modification ofmodel parameters for simulation. The search/exploration component 130may adaptively modify or generate models for simulations based onsimulation results of other models/designs and/or based on triggers anddata from other facilities of the platform 104.

The analysis facility 108 may be configured to analyze simulationresults of designs. The analysis facility 108 may include a filteringcomponent 120. The filtering component 120 may be configured to use oneor more numerical and/or analytical methods to evaluate and compare theperformance of evaluated designs. The filtering component may identifyoptimal or near-optimal designs for one or more performance parameters.The filtering component may search the performance space and identify aset of optimal and/or near optimal designs for one or more performanceparameters.

The analysis facility 108 may include a recommendation component 122.The recommendation component 122 may provide design recommendations. Thedesign recommendations may be based on optimal or near-optimal designsdetermined by the filtering component 120. Recommendations may beadaptive based on settings, feedback, selections, triggers, and the likefrom the user, and/or other facilities in the platform 104.

The analysis facility 108 may include an augmenting component, 124. Theaugmenting component may supplement simulation results with real-worlddata.

The interfaces facility 112 may be configured to provide visualizationsand interfaces for comparing, searching, and evaluating simulateddesigns. Visualization component 132 may provide for one or moreinterfaces to visualize the performance of designs and facilitatecomparison of designs by a user. The feedback analysis component 134 maytrack user actions associated with the interfaces and visualization todetermine patterns and/or preferences for designs. The tradeoff advisorcomponent 136 may analyze and provide data and guidance for evaluatingtradeoffs between two more designs.

The platform 104 may include and/or provide access to one or more datafacilities 138. Data in the data facilities may include design histories140, simulation data 142, site data 144, resource data 146, populationdata 148, and the like.

FIG. 2 shows aspects of an embodiment of a process for trial design. Theprocess may include four or more stages. Facilities of the platform 104may be configured to implement the stages of the process. The stages ofthe process may include a configure stage 202. The configure stage 202may define one or more the spaces associated with the trial design. Theconfigure stage 202 may define one or more of criteria space 210, designspace 212, scenario space 214, and/or performance space 216. Theconfigure stage 202 may utilize one or more advisors, wizards,algorithms, and the like for defining the spaces. In some embodiments,the different spaces associated with the configuration stage 202 may bedefined by different members of a team based on the expertise of themembers. In some cases, members of a team may have differentspecializations. For example, some members may specialize in scenarios,while others may specialize in design definitions. Separating the inputsmay allow different team members to independently optimize and improvespecific models without affecting other inputs. In some embodiments, theinputs may be separated into two or more types based on convenience,expertise, flexibility, and the like.

The stages of the process may include an evaluate stage 204. Theevaluate stage 204 may configure models 218 for evaluation usingsimulation 220 and analytical methods 224. The stage may include variousmethods of enhancing computation and simulation using parallelizationand resource management 222.

The stages of the process may include an augment stage 206. The augmentstage 206 may add real-world data to the simulation data. Financial data226, regulatory data 228, revenue data 230, and the like may be added tothe and used to augment data from simulations.

The stages of the process may include an explore and analyze stage 208.The explore and analyze stage 208 may include filtering methods andalgorithms 232 for identifying optimal designs. The stage may includegenerating and interacting with visualizations 234 and tradeoff analysistools 236 to compare and select designs.

In embodiments, the platform may be configured for identification andconfirmation of globally optimal trial designs. Optimality of trialdesigns may be in relation to optimality criteria. Optimality criteriamay be determined in relation to the performance space of designs.Optimality may be in relation to one or more performance parameters andthe values of the performance parameters. An optimal design may be adesign that achieves a most desirable value for one or more specificperformance parameters. A most desirable value may depend on theperformance parameter and may be different for each performanceparameter. In some cases the most desirable value may be the highestvalue of a performance parameter. In some cases, the most desirablevalue may be the lowest value of a performance parameter. In some cases,the most desirable value may be a range of values, a specific value, afunction of values, and the like. For example, in some cases an optimaldesign with respect to a cost performance parameter may be a design thathas the lowest cost and achieves the goals of the clinical trial. Asanother example, an optimal design with respect to a time performanceparameter may be a design that has the highest NPV and achieves thegoals of the clinical trial. Optimality may be determined for differentdesign types and/or different phases of a trial. In embodimentsdifferent optimality criteria may be used for different designs and/ordifferent phase of a trial.

In embodiments, an optimum design is a design that achieves mostdesirable values for two or more specific performance parameters. In thecase of optimality for multiple performance parameters, optimality mayrequire a tradeoff between the parameter values. For example, a designthat has the lower cost may have a low NPV and therefore may not bedesirable. The optimality of a design may be based on a function ofperformance parameters. In some cases, a function may be a weighted sumof the performance parameters. A function, or a set of functions, may beused to generate an overall score (or a set of scores) and the score maybe used to determine the optimality of the design. A highest score, aspecific score, lowest score, and the like may be considered optimaldepending on the function used to compute the score.

In embodiments, optimality may be evaluated according to Paretooptimality. Pareto optimal designs may be designs where no individualperformance parameter can be better off without making at least oneother individual performance parameter worse off. In some cases,optimality may be determined using convex hull analysis.

In some cases, one design may be globally optimum. In some cases, morethan one design may be globally optimum. In some cases, no designs maybe globally optimum. In some embodiments, optimality of designs may berelative to a benchmark. A known design, a set of historical designs,and/or the like may be used as a benchmark. Designs may be consideredoptimal if they meet, exceed, and/or are within a threshold distance ofthe benchmark design performance parameters.

Performance parameters that may be used to determine design optimalitymay be user defined, system defined, algorithmically defined, and/or thelike. In some cases, users may specify a subset of performanceparameters that should be used to identify optimal designs. A user maydefine optimality criteria by defining ranges, values, characteristics,and the like of the parameter values that may be considered desirableand/or optimal. Interactive graphical interfaces may be provided to auser to evaluate different designs based on one or more optimalitycriteria. Interactive interfaces may allow a user to explore differentdesigns by changing scoring methods, weights associated with thecriteria, and the like.

In embodiments, the characteristics of performance parameters forevaluated designs may be analyzed by the platform to determine if any ofthe parameters may be less important for optimality. For example,analysis may include evaluation of ranges, variability, and otherstatistical analysis. If one or more performance parameters for allevaluated designs is within a desirable range, or the performanceparameter is almost equal for all of the evaluated designs, theperformance parameter may be removed and identified as less significantfor optimality and, in some cases, may not be factored in whendetermining optimality. Prior to determining optimality on based onperformance parameters, the performance parameters and the values of theperformance parameters may be grouped, filtered, normalized, and thelike.

Optimality of designs may be redefined automatically,semi-automatically, in response to user input, and/or the like. Thecriteria for optimality of designs may change as designs are evaluatedby the platform. For example, initial optimality criteria may produce nooptimal designs. In response to no optimal designs being determined, thecriteria may be changed (relaxed, increased, decreased, etc.) until atleast one design is considered optimal. In another example, optimalitycriteria may change in response to user feedback. Users may evaluateinitial designs found to be optimal and provide feedback (directfeedback and/or indirect feedback that can be derived from user actionsand inactions). The feedback from the user may be used to change howoptimality is determined, which performance parameters are used todetermine optimality, the values of the performance parameters that areconsidered optimal, and/or the like.

In some embodiments, performance parameters may be grouped, ordered,and/or organized into one or more hierarchies, groups, and/or sets. Twoor more different optimality criteria may be used in parallel todetermine multiple sets of optimal designs under different criteria. Twoor more different optimality criteria may be used sequentially todetermine optimal designs. One criteria may first be used to identify afirst set of optimal designs under first criteria. A second set ofcriteria may then be used on the first set to reduce the set of optimaldesigns.

In embodiments, a design may be globally optimum if the design isoptimal with respect to all possible design options. In embodiments, adesign may be globally optimum if the design is optimal with respect topossible design options for one or more criteria. In embodiments, adesign may be globally optimum if the design is optimal with respect toa large percentage (such as 80% or more) of possible design options forone or more criteria. In embodiments, a design may be globally optimumif the optimality of the design is within a high confidence level (90%confidence) with respect to possible design options for one or morecriteria.

Traditional methods for evaluating designs cannot determine globaloptimum designs since they evaluate one, several, or a small subset ofdesign options. Traditional methods do not consider all or almost all ofthe design options and cannot find a global optimum.

Trial designs may involve numerous variables, parameters,considerations, tradeoffs, and the like resulting in a very large numberof possible variations. A large number of possible variations makesstudy design and optimization using traditional methods difficult. Inmany cases, traditional methods may fail to explore or consider thecomplete space of possible trial design options and may miss or neverconsider globally optimal designs. Using traditional methods, the numberof design variations that may be explored in a reasonable time islimited. In some cases, only one (1) statistical design and only three(3) clinical scenarios may be evaluated. The best design study of thelimited number of variations may not result in a globally optimaldesign. A locally optimum design chosen from a limited number ofconsidered designs may represent one (1) local maximum but may be farfrom the globally optimum design. When 10,000 or more clinical scenariosare considered, a globally optimum design may be distinguished from themany locally optimum designs. However, consideration of 10,000 clinicalscenarios cannot be practically performed using traditional methods asit would require an estimated 50,000 hours or more to complete.

In embodiments, the platform and methods described herein may evaluatethousands or even millions of design options enabling a determination ofa global optimum design. In many cases, the globally optimum design mayhave significant advantages over locally optimum designs. In oneexample, a globally optimum design may require less time to completethan other designs.

Referring again to FIG. 1, the platform 104 may receive and/or determineperformance space using the configuration facility 106. Performancespace may be defined in the space definitions component 116. Theperformance space may be configured based input from users and/or basedon data 138 such as history data 140 and/or simulation data 142. In oneinstance, performance space may define optimality criteria. Optimalitycriteria may define performance parameters, performance values,functions, methods, and algorithms for evaluating optimality and/orglobal optimality of designs. In one instance optimality criteria may beconfigured by the user or determined from benchmark designs from history140 and/or simulation 142 data. In another instance, optimality criteriamay be defined from simulation data from the simulation facility 110.Optimality of designs may be determined in the analysis facility 108.The filtering component 120 may be used to determine one or more sets ofglobally optimum designs from the designs evaluated by the simulationfacility 110.

FIG. 3 shows aspects of an apparatus for determining global optimalityof designs. In embodiments, the optimality analysis component 302 may bepart of the analysis facility 108 of the platform 104. The optimalityanalysis component 302 may receive data from simulated designs 312 anddetermine one or more sets of optimal designs 322, 324. The optimalityanalysis component 302 may include one or more circuits for determiningoptimality of designs. In embodiments, the optimality analysis component302 may include circuits for determining optimality based on optimalityfunctions 328. Optimality functions 328 may determine optimality ofdesigns based on different weighting of performance factors of thesimulated designs. In embodiments, the optimality analysis circuit 302may include circuits for determining optimality based on benchmarkanalysis 304. Benchmark analysis circuit 304 may determine optimality ofdesigns based on a comparison of performance parameter values to one ormore benchmark designs such as from historical data 314 and/orsimulation data 312. In embodiments, the optimality analysis circuit 302may include circuits for determining optimality using sequentialanalysis 308 and/or parallel analysis 310. Sequential analysis circuit308 and parallel analysis circuit 310 may use one or more differentoptimality functions 328 in parallel or sequentially to determineoptimal designs. In embodiments, the optimality analysis circuit 302 mayinclude circuits for dynamically modifying optimality criteria 306. Userinputs 320, simulation data 312, and/or the determined sets of optimaldesigns may be monitored and analyzed to determine modifications tooptimality criteria. In embodiments, the optimality analysis circuit 302identifies a confidence level 326 associated with the optimality of setsof optimal designs. In the case where simulation data 312 may notinclude simulations of all design options for the criteria space 318,the optimality circuit 302 may determine, based on the simulateddesigns, a confidence level that the determined optimal designs areindeed optimal for a given optimality criteria.

FIG. 4 shows aspects of an apparatus for determining global optimalityof designs. In embodiments, the apparatus may include an optimalityanalysis circuit 414 which may be part of the analysis facility 108 ofthe platform 104. In embodiments, the apparatus may include a dataprocessing circuit 406 structured to interpret/obtain design data 402 ofa clinical trial design. In some embodiments the design data 402 may beoutputs of simulation data of trial designs. The data processing circuit406 may transform the design data 402 into a format suitable for use bythe various circuits in the apparatus. For example, the design data 402may be received by the data processing circuit 406 and determine andidentify performance parameters in the data. In some embodiments, someperformance parameters may be grouped, filtered, converted, normalized,and the like.

The apparatus of FIG. 4 may further include an optimality determiningcircuit 408 structured to receive processed design data from the dataprocessing circuit 406. The optimality determining circuit 408 mayidentify globally optimum designs 412 based on one or more optimalitycriteria. In some embodiments, the globally optimum designs 412 may beprovided as an output of the apparatus. In some embodiments, globallyoptimum designs 412 may be further processed by the design analysiscircuit 410. The design analysis circuit 410 may analyze the globallyoptimum designs 412, determine characteristics of the designs, andreceive feedback data 404 about the designs. The design analysis circuitmay, based on the determined characteristics, determine modificationsfor optimality criteria used in the optimality determining circuit 408.Using modified optimality criteria, the optimality determining circuit408 may determine a new set of globally optimum designs 412.

As shown in FIG. 5, a method for determining globally optimum designsmay include simulating all design options for a design criteria 502. Themethod may further include determining an optimality criteria forevaluating simulated designs 504. Optimality criteria may be a functionof one or more performance values for each design such as a weighted sumof the values, a comparison of the values, and the like. The method mayinclude searching for globally optimum designs in the simulated designsusing the determined optimality criteria 506. The globally optimumdesigns may be recommended to one or more users 508.

As shown in FIG. 6, a method for determining globally optimum designsmay include simulating design options for a design criteria 602. Themethod may further include determining a first optimality criteria forevaluating simulated designs 604. The method may further includedetermining a first optimality criteria for evaluating simulated designs606. In the next step, the method may include determining a first set ofoptimum designs using the first optimality criteria, the first set maybe determined from the simulated designs 608. The method may furtherinclude determining a second set of optimum designs using the secondoptimality criteria, the second set may be determined from the first setof designs 610. The globally optimum designs may be recommended to oneor more users 612.

As shown in FIG. 7, a method for determining globally optimum designsmay include simulating design options for a design criteria 702. Themethod may further include determining a first optimality criteria forevaluating simulated designs 704. In the next step, the method mayinclude determining a first set of optimum designs using the firstoptimality criteria, the first set may be determined from the simulateddesigns 706. The method may further include identifying characteristicsof designs in the first set of globally optimum designs 708. The methodmay further include determining a second optimality criteria forevaluating simulated designs based on the identified characteristics710. The next step of the method may include determining a second set ofglobally optimum designs using the second optimality criteria from thesimulated designs 712.

In embodiments, the platform may be configured for identification andconfirmation of globally optimal trial designs across one or more ofdesign space, scenario space, criteria space, or performance space. Inembodiments, the determination of an optimum design requires a carefulbalance to ensure that relevant parameter permutations are consideredbut that time, cost, and the like are not wasted on needless simulationsand evaluation of designs that are not relevant. In embodiments, theplatform enables the surfacing and consideration of all relevantparameters for evaluating a design while not needlessly wastingresources.

In embodiments, the platform may support global optimization of clinicaltrial design by connecting criteria space, design space, scenario spaceand performance space. The platform may provide users withvisualizations for interactive exploration of the spaces. The platformmay support global optimization by enabling design optimization andexploration across different styles of explorations. Users of differentexperience, knowledge, and/or expertise may explore or optimize forelements that are within their expertise/knowledge and share and exploredata with users of the same or different expertise/knowledge.

In embodiments, globally optimum trial design may include definingcriteria space. In some embodiments, defining and configuring criteriaspace may be a prerequisite to defining and configuring other spaces.Configuration space may be at least partially defined and configured bya user. In some embodiments, expert users may define all or a largeportion of the criteria space. In some embodiments, a user may directlydefine a portion of the criteria space and/or provide general aspects orgoals for the study and the platform may use one or more advisors (suchas the design advisor described herein), historical data, and AI/MLmodels of historical study data to define and configure the criteriaspace. In embodiments, the criteria space definitions may be used by theplatform to determine parameters for design space, scenario space,and/or performance space. In embodiments, the scenario space parametersmay be automatically reviewed for consistency and errors and anycontradictions in parameters may be flagged for review by a user.

In embodiments, scenario space parameters may be analyzed to determinethe breadth of the constraints of the parameters. In some cases, theplatform may determine or estimate aspects such as size of the designspace (for example, number of design options that will need to besimulated), complexity of the design space (for example, number ofparameters) size of the scenario space (for example, number of scenariosthat will need to be simulated), complexity of the scenario space (forexample, number of parameters), size of the performance space (forexample, number of performance parameters that need to be tracked insimulation), and the like based on the configuration of the criteriaspace. The estimates on sizes, complexity, and the like may provide aguide as to the breadth of the criteria space definitions. The estimatesmay be determined from historical data, may be algorithmicallydetermined, and/or estimated via one or more tables that provide acorrespondence between the criteria space parameters and other spaces.

In some cases, criteria space may be identified (automatically by theplatform or by the user) as being too constricting (such as notresulting in a meaningful number of design options for simulation) or tobroad (such as resulting in an extremely large number of design optionsto be simulated) and the platform may identify ways to broaden and/ornarrow the criteria space. In one embodiment, parameters of the criteriaspace may include relations and dependencies. The platform may surfaceand identify criteria space parameters to add (typically to narrow thebreadth) or to remove certain constraints from the criteria space(typically to increase the breadth) based on the relations anddependencies in the parameters.

In embodiments, the criteria space definitions may be used to define thedesign space. Design space definitions may include ranges of values forone or more design space parameters. The design space may be developedby defining design options by taking a cross product of all thepermutations of the values of the design space parameters. Each of theresulting design options may be verified to determine if the permutationof parameters for the design resulted in a valid design option and/orconsistent with the criteria space constraints. Invalid permutations maybe removed or flagged to avoid needless simulation.

In embodiments, the criteria space definitions may be used to define thescenario space. Scenario space definitions may include ranges of valuesfor one or more scenario space parameters. The scenario space may bedeveloped by defining scenario options by taking a cross product of allthe permutations of the values of the scenario space parameters. Each ofthe resulting scenario options may be verified to determine if thepermutation of parameters for the scenario resulted in a valid scenariooption and/or consistent with the criteria space constraints. Invalidpermutations may be removed or flagged to avoid unnecessary simulation.

In embodiments, a cross product of all the valid scenario options fromthe scenario space and all the valid design options from the designspace may be used to generate models for simulation. Each of theresulting scenario-design permutations may be verified to determine ifthe permutation resulted in a valid permutation and/or is consistentwith the criteria space constraints. Invalid permutations may be removedor flagged to avoid unnecessary simulation.

In some embodiments, the set of scenario-design permutations may bepruned to remove permutations that are determined to have poorperformance parameters or are predicted to not meet the criteria. Insome cases, a database of previous simulations may be compared to theset of permutations to identify preliminary predictions.

Models for the valid scenario-design permutations may be simulated usingone or more engines to determine performance of the designs. Thesimulations may track and evaluate performance space of each designaccording to the criteria space definitions. The simulated data may beanalyzed to determine optimum designs. Various visualizations andanalysis interfaces (such as card interfaces, heat maps, and tornadodiagrams as described herein) may be provided by the platform forvisualizing and identifying performance of designs. The systematicdevelopment of criteria, design, scenario, and performance spaces andtheir respective permutations ensures that all relevant design optionsare considered and evaluated for determining globally optimum designoptions.

Referring to FIG. 1, the configuration facility 106 of the platform 104may include components for defining the criteria space, design space,scenario space, and performance space. In embodiments, advisorcomponents 114 may be used to define criteria space and further definespace definitions using the space definitions component 116. Thecombinations component 118 may determine permutations and combinationsand may identify invalid or unnecessary combinations of parameters for acriteria. The combinations may be used to define models in the modelscomponent 126 for simulation. The models may be simulated by thesimulation facility 110 and analyzed by the analysis facility 108.

FIG. 8 shows aspects of an apparatus for defining criteria, design,scenario, and performance spaces for trial design. In embodiments, thespace definition component 802 may be part of the configuration facility106 of the platform 104. The space definition component 802 may receivespecifications for user input 820 or from one or more input/designadvisors 830. The inputs may identify definitions and constraints on oneor more spaces. From the input, the criteria definitions component 804may identify criteria parameters that may identify constraints on thestudy. In embodiments size/complexity estimator 808 may provide data andestimates with respect to how criteria definitions relate to the numberof design options and scenario options that will be simulated for thecriteria. Estimates may be determined from previous simulation data 818.The size/complexity estimator 808 may initiate criteria revisions. Insome embodiments, parameter relations component 806 may surface settingsand parameter relations to identify constrains and/or parameters thatmay be added, removed, or redefined in the criteria. A validity checkercomponent 810 may verify that criteria space parameters are consistentand may flag any issues that should be addressed. Based on the criteriaspace definitions 822, the design parameters component 812 may determineranges and values for one or more design parameters that meet thecriteria. The design parameters component 812 may identify validpermutations of the design parameters and define the design space 824.Based on the criteria space definitions 822, the scenario parameterscomponent 814 may determine ranges and values for one or more scenarioparameters that meet the criteria. The scenario parameters component 814may identify valid permutations of the scenario parameters and definethe scenario space 826. The performance parameters component 816 mayidentify performance parameters that should be tracked based on thecriteria and define the performance space 828.

As shown in FIG. 9, a method for evaluating a design may includeobtaining a criteria for a trial design study 902. The criteria may beobtained from the user or from other parts of the platform based on auser input and/or historical data. The method may further includedetermining permutations for designs based on the criteria 904 anddetermining permutations for scenarios based on the criteria 906. Forexample, depending on the criteria, it may be possible to affirmativelydetermine design permutations or scenario permutations that are feasiblein view of the criteria, and/or it may be possible to determine specificdesign permutations or scenario permutations that are not feasible inview of the criteria (e.g., cannot possibly provide a result thatsatisfies the criteria). For example, if a user inputs as a designcriterion a specific maximum drug dose, then only design permutationshaving a dose of drug equal to or less than the specified maximum drugdose will be included (all other design permutations are infeasible inview of specified criterion, because it is not possible for them toachieve a drug dose that does not exceed the specified maximum).Alternatively or in addition, if a user inputs as a scenario criterion aspecific range of patient dropout rates (for example), then onlyscenario permutations having a patient dropout rate within the specifiedrange will be included. Furthermore, the method may include generatingcombinations using the permutations of designs and scenarios 908. Insome embodiments, the combinations may be exhaustive, i.e., thecombinations to be simulated include each possible design permutationcombined with each possible scenario permutation (or, if infeasiblepermutations are first excluded, the combinations to be simulatedinclude each feasible design permutation combined with each feasiblescenario). Alternatively, in some embodiments, some combinations may beremoved based on predicted performance. As discussed further below, avariety of heuristics, algorithms, filters, or the like may be used topredict that certain combinations are improbable or unlikely to achievea desirable outcome. In some embodiments, analysis of data from pasttrials, or information input by one or more users, may indicateimprobable combinations for which simulation would be of minimal value.For example, historical trial data and/or guidelines based on userexperience may indicate a direct relationship between trial duration andpatient dropout rates, such that a patient dropout rate below a certainlevel is unlikely to be achieved for a trial having a duration thatexceeds a certain time period. Therefore, although combinations havingcertain patient dropout rates and certain trial durations may satisfyall selected criteria, it can be predicted that such combinations eithercannot be achieved as a practical matter or cannot result in asatisfactory trial outcome. Therefore, such combinations can be removedprior to the simulation. As another example, analysis of past trial datamay indicate that drug doses below a certain level are rarely effectivein treatment of certain conditions, and combinations involving low drugdoses may be predicted to perform poorly and therefore be removed priorto simulation. Also, as discussed further below, a scoring system may beimplemented to predict performance and determine combinations thatshould be removed prior to simulation. The combinations that aredetermined to be appropriate for simulation (which may be all possiblecombinations in some embodiments or a subset of combinations in otherembodiments) may be simulated 910 and the performance of the simulateddesigns may be determined and analyzed 912. The evaluated performanceparameters may be based on the criteria and/or based on goals orperformance objectives other than the obtained criteria.

As shown in FIG. 10, a method of evaluating designs may includeobtaining a criteria for trial design study 1002. The method may furtherinclude predicting design simulation requirements based on the criteria1004. The predictions may include how many simulations will need to beperformed, the cost of the simulations, the time for the simulations,and the like. For example, based on the obtained criteria, a number ofpotential design permutations may be determined, and a number ofpotential scenario permutations may be determined. A cross product ofthe number of design permutations and the number of scenariopermutations can indicate the number of combinations to be simulated,and based on system parameters that number can be used to alsodetermine, for example, the time required to simulate that number ofcombinations, the cost of the simulations, and the like. The method mayinclude modifying the criteria based on the predictions 1006. Thecriteria may be modified to constrain the criteria to reduce the numberof needed simulations or broaden the criteria to include more designoptions for simulation. As one example, if the predicted number ofrequired simulations is very large for when an obtained criteria relatesto a maximum trial duration, the criteria may be modified to includeboth a maximum and a minimum trial duration (in situations where a veryshort trial duration is deemed unlikely to provide a successful result).In some embodiments, controls (for example, slider bars) may be providedto a user to adjust values for selected criteria so that the user canquickly see the impact that changes to the criteria have on thepredicted number of required simulations, the duration of thesimulation, the cost of the simulation, etc. The method may includegenerating design and scenario combinations based on the modifiedcriteria 1008 and determining performance parameters that should bedetermined based on the criteria 1010. The combinations may be simulatedto obtain the performance parameters determined for each design. Themethod may further include simulating combinations and determiningperformance designs 1012.

FIG. 11 shows aspects of an apparatus for determining designs. Inembodiments, the apparatus may include a space definition circuit 1102which may be part of the simulation facility 110 of the platform 104. Inembodiments, the apparatus may include a criteria analysis circuit 1104structured to interpret/obtain criteria data 1112. The criteria data maybe analyzed by the simulation prediction circuit 1120 to determineaspects of simulation time, design options, and the like that areconsistent with the criteria. The predictions 1122 from the simulationprediction circuit 1120 may be provided to a user and feedback 1114 maybe received for modification of the criteria. The design space circuit1106 and the criteria space circuit 1108 may generate the design andperformance parameters from the criteria. The combinations circuit 1110may generate design-scenario combinations 1118 for simulation. In someembodiments, a validity circuit 1124 may determine the validity of anycombinations 1118 or any design space or scenario space parameters andthe invalid options may be removed. The combinations 1118 and theperformance space 1116 determined from the criteria by the spacedefinition circuit 1102 may be used to simulate and analyze designs.

Referring to FIG. 12, an embodiment of an interface 1210 for configuringand managing an execution flow 1212 for a clinical trial designevaluation is shown. In embodiments, the interface 1210 may form part ofthe configuration facility 106 (FIG. 1). The interface 1210 may also beprovided by a system separate from the platform 104 (FIG. 1) andcommunicate with the platform 104 via one or more applicationprogramming interfaces (APIs) or otherwise. The interface 1210 may beprovided as a graphical user interface on one or more user devices 102(FIG. 1).

As can be seen in FIG. 12, the execution flow 1212 defines, in part, oneor more processes and the order in which they occur for conducting oneor more clinical trial design evaluations. The interface 1210 mayinclude a canvas area 1214 for visualizing/editing/creating theexecution flow 1212 using nodes 1216 and arcs 1218. For example, nodes1216 and/or arcs 1218 may be dragged on and/or off the canvas area 1214,wherein the nodes 1216 and arcs 1218 on the canvas area 1214 define, inpart, the execution flow 1212.

Each node 1216 may represent one or more modules and/or processesincluded in the execution flow 1212, wherein the arcs 1218, e.g.,arrows, connect the nodes 1216 so as to define the flow of data from onenode 1216 to another. Non-limiting examples of the types of processesthe nodes 1216 may represent include: an execution engine from component128 (FIG. 1); reception and/or obtaining one or more of design criteria,performance criteria/parameters, scenario criteria; a search/explorationmodule from component 130 (FIG. 1), e.g., simulated annealing;visualizations and/or interfaces to be presented from component 132(FIG. 1); and/or any type of parameter, model/engine, and/orvisualization described herein. Users of the interface 1210 may changethe configuration of the execution flow 1212 by changing nodes 1216,adding nodes 1216, removing nodes 1216, moving arcs 1218 to change theflow of outputs from one node 1216 to the next, and/or the like.

Illustrated in FIG. 13 is another embodiment of an interface 1310 forconfiguring and managing an execution flow for a clinical trial designevaluation, in accordance with an embodiment of the current disclosure.A first node 1312 may represent a set of design parameters to beacquired/obtained and sent to a second node 1314, as indicated by arc1316. Node 1314 may represent an engine that processes the set of designparameters to generate outputs as represented by arc 1318 and node 1320.Arc 1322 depicts the outputs being communicated to an unconfigured node1324. As shown in FIG. 13, a menu 1326 may be generated within and/ornear the unconfigured node 1324 and provide options for configuring thenode 1324. For example, using the menu 1326 a user may configure thenode 1324 to represent a sensitivity analysis, e.g., a tornado plot, avisualization, and/or an optimization method/engine, e.g., simulatedannealing. The menu 1326 may also provide a general option to save thestate of the interface 1310 and/or corresponding execution flow 1328.Node 1330 represents a visualization that has not yet been incorporatedinto the execution flow 1328, i.e., no arcs connect node 1330 into theexecution flow 1328. In embodiments, the interface 1310 may include amenu 1332 that provides a user with options to add parameter input nodes1334, engine nodes 1336, arcs 1338, visualizations 1340, complex arcs1342, e.g., forks, a save option 1344, and/or the like.

Referring now to FIGS. 14 and 15, in embodiments, the interface may beconfigured for different user types/target audiences. Distinctinstances/views of the interface may be generated wherein eachinstance/view is tailored for a particular user type/role and/or aconfiguration level. In embodiments, an instance/view may be fordefining analysis aspects and may include a focus, as well as additionalinterfaces and/or options for viewing and/or editing greater details ofthe execution flow, e.g., specifying algorithms, performance criteria,and the like. In embodiments, an instance/view may be for definingdesign and/or scenario aspects and may include, for example, additionalinterfaces and options for importing design parameters from a previousanalysis. Analysis templates, e.g., collections of nodes 1216 and arcs1218, may be used in the execution flow 1212 to provide a baselineconfiguration. Analysis templates may include templates for a low-costanalysis (i.e., use of low-cost engines), exhaustive analysis, andheatmap analysis (i.e., which visualizations are to be provided). Inembodiments, different views may depict aspects of the same data todifferent users at the same time. For example, a user associated with aregulatory organization may see only results of the analysis, whileanother user may have access to additional features that provide forconfiguration of the analysis. Changes to the configuration of theanalysis may propagate across multiple views in real-time.

User types may include simulation engine designers, visualizationdesigners, optimization professionals and/or the like, and may besubdivided into skill levels, e.g., expert, intermediate, and/or novice.Configuration levels may provide for different levels of access overparts of an execution flow and may be categorized as high, medium, orlow, wherein a high level provides for more access than a medium levelwhich provides for more access than a low level. In embodiments, otherclassification schemes for user types and configuration levels areprovided.

For example, a first instance/view of the interface 1410 may beconfigured for a first user type 1510 and a second instance/view of theuser interface 1412 may be configured for a second user type 1512. Inembodiments, the user types may correspond to skill levels and/ordifferent specialties with respect to clinical trial design. Forexample, the first user type 1510 may be a subcategory of a user type1514 corresponding to a simulation engine designer. User type 1510 maycorrespond to an expert simulation engine designer and have siblingtypes corresponding to intermediate simulation engine designer 1516and/or novice simulation engine designer 1518. User type 1512 may be asubcategory of a user type 1520 corresponding to a visualizationdesigner. User type 1512 may correspond to a novice visualizationdesigner and have a sibling corresponding to an expert visualizationdesigner 1522.

Accordingly, view 1410 provides user type 1510 access to morefunctionality and/or control over configuration of the execution flow1212 within an engine 1414 as compared to view 1412 for user type 1512.For example, interface 1410 provides access to nodes 1416 and 1418within the engine node 1414, while interface 1412 provides onlyhigh-level access to the engine node 1414. Thus, interface 1410 allowsan expert simulation designer 1510 to configure the execution flow 1212internal to an engine while interface 1412 prevents a non-expertsimulation engine designer 1512 from doing the same.

In embodiments, different user types may define parts of the executionflow concurrently. In other words, embodiments may provide for users tocollaborate (concurrently or asynchronously) to design, conductsimulations, and perform analysis on clinical trial designs during bothpre-simulation and post-simulation stages. For example, user type 1510may configure the internals of the engine node 1414 at the same timeuser type 1512 configures a visualization node 1420. Thus, as will beappreciated, users in different geographic regions, e.g., cities,states/provinces, and/or countries, may work together on the sameexecution flow 1212. In embodiments, authentication and access controlmay be used to identify and authenticate users and control access to oneor more functions and/or resources accessible by the platform. Inembodiments, users may have different permissions allowing differentaccess and actions. For example, some users may be provided with theability for configuring a flow but require another user or anotherauthorization level to execute the flow.

Turning now to FIG. 16, a method 1600 for configuring an execution flowfor a clinical trial design evaluation is provided. The method 1600includes configuring an execution flow for a clinical trial designevaluation using a configurable interface 1610, as described herein. Theconfigurable interface 1210 (FIG. 12) may include at least one nodeelement 1216 and at least one arc element 1218. The execution flow 1212may be defined, in part, via the at least one node element 1216 and theat least one arc element 1218 (FIG. 12), as disclosed herein. The method1600 includes executing the clinical trial design evaluation using theexecution flow 1612. The method 1600 includes reconfiguring at least oneof the at least one node element or the at least one arc element in theexecution flow 1614. Reconfiguring may include one or more of adding,removing, moving, and/or otherwise adjusting the at least one nodeelement and/or the at least one arc element. The method 1600 furtherincludes executing the clinical trial design evaluation using thereconfigured execution flow 1616.

FIG. 17 depicts another method 1700 for configuring an execution flowfor a clinical trial design evaluation. The method 1700 includesconfiguring an execution flow for a clinical trial design evaluationusing a configurable interface 1710, as disclosed herein. The executionflow 1212 may be defined using at least one node element 1216 and atleast one arc element 1218, as described herein. The method 1700 furtherincludes determining a first user type interacting with the executionflow 1712, e.g., attempting to and/or preparing to configure theexecution flow 1212. The method 1700 further includes configuring afirst view of the execution flow for the first user type 1714. Themethod 1700 further includes determining a second user type interactingwith the execution flow 1716 e.g., attempting to and/or preparing toconfigure the execution flow 1212. The method 1700 further includesconfiguring a second view of the execution flow for the second user type1718.

Illustrated in FIG. 18 is an apparatus 1800 for configuring an executionflow for a clinical trial design evaluation. The apparatus 1800 includesan interface configuration circuit 1810 structured to generate interfacedata 1812 corresponding to a configurable interface having a nodeelement 1216 (FIG. 12) and an arc element 1218 (FIG. 12). The nodeelement 1216 and the arc element 1218 define execution flow data 1814for a clinical trial design evaluation, i.e., the flow data 1814corresponds to the execution flow 1212 (FIG. 12). The apparatus 1800further includes a user input circuit 1816 structured to interpret userinput data 1818 based at least in part on the node element 1216 and thearc element 1218. The apparatus 1800 further includes an interfacereconfiguration circuit 1820 structured to reconfigure the executionflow data 1814 to generate, based at least in part on the user inputdata 1818, reconfigured execution flow data 1822. The apparatus 1800 mayinclude an evaluation circuit 1824 structured to generate evaluationdata 1826 via executing the clinical trial design evaluation based atleast in part on the reconfigured execution flow data 1822. Theapparatus 1800 may further include an evaluation processing circuit 1828structured to transmit the evaluation data 1826.

In embodiments, apparatus for configuring execution flow may enableconfiguration and manipulation of scenario, design, performance, andcriteria spaces. Each space may be separately configured by differentusers. Each space may be associated with one or more different nodes inthe execution flow. The nodes corresponding to each space may bemodified and/or replaced with a different version of the node to changeaspects of any one of the spaces.

Referring to FIG. 19, an advisor 1900, e.g., an interactive wizard oralgorithm, for guiding a user through configuration of trial designsimulations, and/or systems for optimizing clinical trial designselection, is shown. In embodiments, the advisor 1900 may be used forpre-simulation configuration of the platform 104, updating of theplatform 104 during simulation runs, and/or for configuring the platform104 for post-simulation analysis, e.g., configuring searches such asthose provided by the search/exploration component 130 (FIG. 1). Forexample, a user may first log on to the platform 104 and specify via auser interface, e.g., 112 (FIG. 1) that they wish to being a new designevaluation. The platform 104 may then launch an embodiment of theinteractive wizard or algorithm which may then present the user with aseries of initial questions/prompts designed to determine general designand/or performance criteria for one or more designs. The interactivewizard or algorithm may then ask additional questions/prompts todetermine more specific ranges and/or values for the design and/orperformance criteria. Based on the user's inputs/answers to thequestions/prompts, the platform may affirmatively determine designpermutations or scenario permutations that are feasible in view of thecriteria, and/or it may be possible to determine specific designpermutations or scenario permutations that are not feasible in view ofthe criteria (e.g., cannot possibly provide a result that satisfies thecriteria). For example, if a user inputs as a design criterion aspecific maximum drug dose, then only design permutations having a doseof drug equal to or less than the specified maximum drug dose will beincluded (all other design permutations are infeasible in view ofspecified criterion, because it is not possible for them to achieve adrug dose that does not exceed the specified maximum). Alternatively, orin addition, if a user inputs as a scenario criterion a specific rangeof patient dropout rates (for example), then only scenario permutationshaving a patient dropout rate within the specified range will beincluded.

In embodiments, the interactive wizard or algorithm may include a methodof generating combinations that uses the permutations of designs andscenarios. In some embodiments, the combinations may be exhaustive,i.e., the combinations to be simulated include each possible designpermutation combined with each possible scenario permutation (or, ifinfeasible permutations are first excluded, the combinations to besimulated include each feasible design permutation combined with eachfeasible scenario). Alternatively, in some embodiments, somecombinations may be removed based on predicted performance. As discussedfurther below, a variety of heuristics, algorithms, filters, or the likemay be used to predict that certain combinations are improbable orunlikely to achieve a desirable outcome. In some embodiments, analysisof data from past trials, or information input by one or more users, mayindicate improbable combinations for which simulation would be ofminimal value. For example, historical trial data and/or guidelinesbased on user experience may indicate a direct relationship betweentrial duration and patient dropout rates, such that a patient dropoutrate below a certain level is unlikely to be achieved for a trial havinga duration that exceeds a certain time period. Therefore, althoughcombinations having certain patient dropout rates and certain trialdurations may satisfy all selected criteria, it can be predicted thatsuch combinations either cannot be achieved as a practical matter orcannot result in a satisfactory trial outcome. Therefore, suchcombinations can be removed prior to the simulation. As another example,analysis of past trial data may indicate that drug doses below a certainlevel are rarely effective in treatment of certain conditions, andcombinations involving low drug doses may be predicted to perform poorlyand therefore be removed prior to simulation. Also, as discussed furtherbelow, a scoring system may be implemented to predict performance anddetermine combinations that should be removed prior to simulation. Thecombinations that are determined to be appropriate for simulation (whichmay be all possible combinations in some embodiments or a subset ofcombinations in other embodiments) may be simulated and the performanceof the simulated designs may be determined and analyzed. The evaluatedperformance parameters may be based on the criteria and/or based ongoals or performance objectives other than the obtained criteria.

In embodiments, the advisor 1900 may be integrated into the platform104, or the advisor 1900 may be a standalone system apart from theplatform 104. In embodiments, the advisor 1900 may assist in obtaininginput from a user to determine trial design criteria and/or trial designparameters, e.g., values for one or more of criteria space, designspace, and/or scenario space, as described herein. User input may beobtained via one or more interactive interfaces, e.g., 1910, structuredto generate one or more questions/user prompts, e.g., 1912. User inputsmay be compared to historical data, such as data stored in data facility138 (FIG. 1), e.g., previous designs, inputs, and/or outcomes, havingsimilar criteria as that defined by the user input. As will beappreciated, assisting a user through the clinical trial designoptimization process may reduce the amount of time and/or resources(including computing resources and/or associated costs) spent onresearch and/or simulating sub-optimal clinical trial designs for agiven clinical trial. Further, the advisor 1900 may be able to makerecommendations for trial design criteria and/or trial design parametersthat may provide for improved efficiencies over similar trial designoptimizations performed by a human.

Accordingly, in embodiments, the interactive interface 1910 may be agraphical user interface wherein the prompts 1912 may be textboxes,popup dialogue boxes, verbal questions played through a sound and/orvideo file, e.g., .mp4, .wav, etc. The interface 1910 may be providedthough a web interface, e.g., provided through cloud services 152 (FIG.1). The interface 1910 may be generated locally on a user device 102(FIG. 1) and communicate with the platform 104 through one or moreapplication programing interfaces (APIs). Further, while FIG. 19 depictsthe interface 1910 as a graphical user interface, a non-limiting exampleof a command line version of the interface 2010 with textual prompts2012 is shown in FIG. 20.

As shown in FIG. 19, in embodiments, the prompts 1912 may include one ormore of: a prompt 1914 to determine a duration of a clinical trial; aprompt 1916 to determine a number of recommended designs to provide; aprompt 1918 to determine a type of a model to use for simulation and/orsearching/exploration, e.g., whether Pareto and/or convex hull analysisshould be performed; a prompt 1920 to determine whether simulatedannealing should be performed; a prompt 1922 to determine total costs ofa clinical trial; and/or other prompts 1924 for determining any othercriteria relevant to determining a globally optimized design for aclinical trial.

Turning now to FIG. 21, a non-limiting example of a prompt 2100 isshown. In embodiments, the prompt 2100 may include a presentation window2110 having a message box 2112 which may display a textual question tothe user, e.g., “What types of optimization engines would you like touse?” The prompt 2100 may also include one or more input fields 2114 forreceiving the user input. The input fields 2114 may include text boxes,radio buttons, sliders, dropdown menus, checkboxes, and/or othersuitable widgets for receiving user input.

In embodiments, the prompt 2100 may include recommendation fields 2116which may present one or more recommended values to a user for one ormore trial design criteria and/or design parameters. For example, a usermay inform the interface 1910 that they intend to optimize a clinicaltrial of a titration design. The advisor 1900 may then query one or moredatabases in the data facility 138 (FIG. 1) and present the user withone or more recommendations 2116 for one or more trial design criteriaand/or trial design parameters. For example, the advisor 1900 mayrecommend, for a particular trial design, that that a Pareto analysis beperformed in conjunction with a convex hull analysis. The advisor 1900may also provide a recommendation 2116 for an estimated cost of theclinical trial. In embodiments, the recommendations 2116 may be singlevalues and/or ranges for values. In embodiments, a recommendation field2116 may correspond to an input field 2114. For example, an input field2114 may be structured to receive a user input defining a number ofsimulations to run, and a corresponding recommendation field 2116 mayrecommend a specific value or a range for the user to enter into theinput field 2114. In embodiments, a recommendation 2116 may be inresponse to a user selection, e.g., users who select option “A” usuallyselect option “B” and/or usually do not select option “C”. For example,a user may select a first option “A” and then select a second option“C”, wherein upon selecting option “C” a recommendation is generatedinforming the user that most users who pick option “A” select eitheroptions “B” or “D” instead of option “C”.

In embodiments, the user inputs may be compared to historical clinicaltrial designs selected by traditional (human) experts. For example, thedata facility 138 (FIG. 1) may include a history of past clinical trialdesign selections from a plurality of experts, e.g., humans who haveextensive experience optimizing clinical trial designs. The advisor 1900may receive one or more user inputs and query the data facility 138 forpast trial designs having trial design criteria and/or trial designparameters that are the same, and/or nearly the same, as those definedby the user input. The advisor 1900 may then generate and presentrecommendations 2116 for other trial design criteria and/or trial designparameters, outside of the ones corresponding to the user input. Inother words, in embodiments, the advisor 1900 may generaterecommendations 2114 for design criteria and/or trial design parametersfor which a user may not have yet specified and/or know. For example,past clinical trial designs may be categorized (based on type of trial,success of the trial, date of the trial, cost of the trial, and thelike). Past clinical trials may be compared, clustered, analyzed, andthe like to determine variations, similarities, and the like for trialsin the same category. In some cases, based on one or more of theclustering, similarities, and/or variations the platform may generatestatistics about the one or more features of past clinical trials ineach category. The statistics may be used to determine features of trialdesigns that are common in a category and features that are uncommon. Insome cases, common and uncommon features may correspond to desirable andundesirable features respectively. Features that are identified ascommon may be suggested to a user while features that are uncommon maybe flagged for reconsideration. In another example, the platform maygenerate a dynamically changing score for the trial designconfiguration. The score may be a prediction of the likelihood that thestudy will results in a useful design for the study. As a user entersdata about design details they wish to evaluate, the problem they studyis meant to address, and the like, the platform may compare the inputswith a historical record of similar studies and the outcome of thestudies (such as if the study resulted in a selected design, was thedesign implemented, how successful was the design when implemented, andthe like). The system may compare the entered data to the database anddevelop a score according to the similarity of the entered parameters tohistorically successful studies. In some cases, similarity may be basedon a function of all the parameters. The score may be updated in realtime as users enter or change parameters, ranges of values, and thelike. The score may provide a rough guide as to how close the study isto a successful study and what aspects of the parameters may be changedto make the study closer to a successful study.

In embodiments, artificial intelligence/machine learning approaches maybe used to generate the prompts 1912 (FIG. 19) and/or other suggestionsfor a user. The artificial intelligence/machine learning may be trainedvia supervised learning. For example, in embodiments, the artificialneural network may be trained to estimate an expected cost, net presentvalue (NPV), expected NPV, incremental NPV, study cost, incrementalstudy cost, study budget, incremental study budget, time to complete,incremental time to complete, time to market, incremental time tomarket, clinical utility, incremental clinical utility, probability ofregulatory acceptance, incremental probability of regulatory acceptance,probability of success, incremental probability of success, statisticalpower, incremental statistical power, number of patients, incrementalnumber of patients, number of sites, incremental number of sites, studycomplexity, incremental study complexity, operational complexity,incremental operational complexity, dose selected, incremental doseselected, statistical design, incremental statistical design, peakrevenue, revenue at year five (5), other revenue numbers, incrementalrevenue, market introduction, whether market introduction beatscompetition entry, number of treatment arms, hypothesissuperiority/equivalence/non-inferiority, other choices aroundstatistical design, treatment effect, hazard ratio, and other choicesaround estimating the characteristics of the patient population,response, and safety profile, screening criteria, dropout rate, andother choices around modeling/estimating the characteristics andbehaviors of the patient population and other factors that impact howthe study evolves and its likelihood of achieving its goals (howslowly/quickly patients enroll, etc.), site payments and other choicesaround operational aspects of the study that can impact how the studyevolves and its likelihood of achieving its goals, cost per patient,cost per site, or other cost factors, selections made in other projectsof a clinical trial design based on past examples. In embodiments, theartificial intelligence/machine learning may be trained on a trainingset that includes clinical trial designs created by experts and/ordesigns made by other non-expert users. Some embodiments of the trainingset may not account for the outcomes of past clinical trial designs.Some embodiments of the clinical trial training set may account for theoutcomes of past clinical trial designs. In such embodiments, theartificial intelligence/machine learning may structure the prompts 1912to guide a user towards a likely outcome, e.g., a likely global optimumdesign. In embodiments, the artificial intelligence may be trained viaunsupervised learning, e.g., policy-based learning. For example, theartificial intelligence may be directed to make recommendations 2116based on reducing the expected cost of a clinical trial.

Moving to FIG. 22, in embodiments, the advisor 1910 may generate andpresent the prompts 1912 based on one or more stages 2200. For example,a first plurality of prompts 2212 may correspond to a first stage 2214of a clinical trial design configuration process, a second plurality ofprompts 2216 may correspond to a second stage 2218 of the clinical trialdesign configuration process, a third plurality of prompts 2220 maycorrespond to a third stage 2222 of the clinical trial design process,and so on. One or more of the stages 2214, 2216, 2218, and/or 2220 maycorrespond to stages, of a clinical trial, e.g., “phase 0”, “phase 1”,“phase 2”, “phase 3”, etc., to include substages of a “phase”. Inembodiments, a user's inputs to a first plurality of prompts 2212 maydetermine the aspects of a subsequent plurality of prompts 2216. Forexample, a user may input a type of trial design in response to thefirst plurality of prompts 2212, and the second plurality of prompts2216 may seek to elicit input from the user specific to the type oftrial.

Illustrated in FIG. 23 is a method 2300 for guiding a user throughconfiguration of the platform 104 (FIG. 1). The method 2300 may includegenerating an interactive interface 2310, presenting, via theinteractive interface, one or more prompts to a user 2312. The promptsmay be structured to determine one or more trial design criteria. Themethod 2300 may further include evaluating historical design selections2314 to identify one or more trial design parameters based at least inpart on or more trial design criteria.

In embodiments, the advisor may be configured to query and deriveconfigurations for the designs, scenario, performance, and criteriaspace separately. The advisor and interfaces associated therewith may beconfigured to separate questions, wizards, and other interfaces suchthat configurations for the spaces are derived separately. The advisormay be configured to allow a first user configure the design space andanother user configure the scenario space. In embodiments, user inputssuch as type of therapeutic to be tested, budget, and the like may beused to configure the design space and or criteria space. Inembodiments, user inputs such as number of patients may be used toconfigure the scenario space. In embodiments, user inputs such asdesired cost or time to completion may be used to configure theperformance space.

Turning to FIG. 24, in embodiments, the method 2300 may further includesimulating one or more clinical trial designs 2410. The simulations maybe based at least in part on the one or more trial design parameters.The method 2300 may further include presenting, via at least one of theprompts, a recommended value for the one or more trial design criteriaand/or the trial design parameters 2412. The method 2300 may furtherinclude generating the recommended values via artificial intelligencebased at least in part on the historical trial design selections 2414.In embodiments, evaluating the historical trial design selections 2314may include evaluating the historical trial design selections viaartificial intelligence 2416.

Illustrated in FIG. 25 is an apparatus 2500 for implementing the method2300. The apparatus 2500 may be integrated into one or more servers 154,user devices 102, and/or other suitable computing devices. As shown inFIG. 25, the apparatus 2500 may include an interface generation circuit2510 structured to generate interactive interface data 2512 thatincludes one or more user prompts 1912, in accordance with thosedescribed herein. The apparatus 2500 may include an interface processingcircuit 2514 structured to transmit the interactive interface data 2512,and a user input circuit 2516 structured to receive user input data 2518defining one or more trial design criteria and/or trial designparameters. The apparatus 2500 may include a historical evaluationcircuit 2520 structured to identify one or more trial design parameters2522 based at least on part on the trial design criteria via evaluatinghistorical data 2524 corresponding to previously simulated clinicaltrial designs. The apparatus 2500 may further include a simulationcircuit 2526 structured to simulate one or more clinical trial designsbased at least in part on the trial design parameters. The apparatus2500 may further include a recommendation circuit 2528 structured togenerate a recommended value 2530 for the trial design criteria and/orthe trial design parameters. In embodiments, the recommendation circuit2528 may be further structured to generate the recommended value 2530based at least in part on historical trial design selections 2532.

Referring now to FIG. 26, embodiments of the current disclosure mayprovide for augmentation of simulated data with additional/supplementaldata, e.g., real-world data. Real-world data may include actual datafrom clinical trial sites, patients, clinical trials, and/or otherentities and aspects related to one or more parameters used to evaluateclinical trial designs as disclosed herein. For example, simulated data,also referred to herein as simulated outputs, may be generated viasimulating one or more clinical trial designs. The simulated data mayinclude relative and/or general values.

Relative values may include values related to an objective or subjectivescale. Relative values may include a scale (i.e., 0-1, 1-10, 1-100)and/or designators (i.e., high, medium, low). For example, evaluationdata may include a relative scale of a complexity of a trial which maybe based on the number of personnel involved, the steps in a protocol ofthe trial, and the like. Real-world data such as regulatory approvaltimes may be used to estimate how long it will take to receiveregulatory approval for the study. Real world data may include a historyof the time required to receive approval for studies with similarrelative complexity rating. The relative values may be supplemented withthe real-world data by substitution and evaluation with respect tohistorical data and real-world data.

General values may include values or placeholders that may be mapped orrepresentative of other data. The mapping and placeholder may comprisemetadata. For example, a simulation output of a design may specifygeneral values such as number of sites and patients needed for a study.Real-world cost data may be used to determine the real-world cost (in alocal currency such as dollars, for example) for the trial based on thenumber of sites and number of patients. Real-world data may include anaverage cost for a patient and an average cost per site. The generalvalues may be supplemented with the real-world data by computing orsubstituting the real-world cost associated with the number of patientsand sites.

The simulations of the clinical trial designs may be based on one ormore design space parameters, criteria space parameters, scenario spaceparameters, and/or additional types of input parameters suitable forsimulating clinical trial designs. In certain aspects, one or more ofthe input parameters to the simulations of the clinical trial designsmay have an estimated and/or predicted value. For example, themanufacturing cost of a subject drug for an intended clinical trial maybe unknown at the time the simulations of the possible clinical trialdesigns (for testing the subject drug) are first executed/run. In such acase, the initial simulations of the clinical trial designs may use anestimated (or predicted) price of the subject drug. The estimated priceof the subject drug, and/or other input parameters, may be based atleast in part on historical data. Real data may then be used incomputations to relate the simulation data to real-world or currentvalues. Thus, in the foregoing example, the actual price of the subjectdrug, when it becomes available, could be used to augment the initialsimulations.

Real-world data may also be used to associate relative values withreal-world absolute values. For example, simulation data may identifygeneral or relative parameters that may influence cost. Additional data(such as current cost data) may be used to determine how these generalparameters translate to real dollar values. Relative data may besubstituted with additional data to provide current values for cost,time, and other performance data. Relative and absolute values may betagged with metadata for marking for substitution.

As shown in FIG. 26, a method for augmentation of simulated data 2600may include obtaining a set of simulation outputs for a set of clinicaltrial designs 2610. The method 2600 may further include obtaining a setof supplemental data 2612. The method 2600 may further includedetermining a relationship between at least one simulation output of theset to at least one supplemental data of the set 2614. The method 2600may further include generating modified supplemental data based at leastin part on the relationship 2616. The method 2600 may further includegenerating a substitute of the at least one simulation output based atleast in part on the modified supplemental data 2618. The method 2600may further include transmitting the substitute 2620.

Illustrated in FIG. 27 is an apparatus 2700 for performing aspects ofthe method 2600 (FIG. 26). In embodiments, apparatus 2700 may be one ormore processors, as described herein, that form part of the augmentingcomponent 124 of the analysis facility 108 of the platform 104. Inembodiments, the apparatus 2700 may be one or more processors of amobile electronic device, e.g., a tablet or smart phone. The augmentingcomponent 124 may receive data evaluation data such as from thesimulation facility 110. The augmenting component 124 may analyze thedata from the simulation facility 110 and identify elements in the databased on tags, values, locations, and the like. The augmenting component124 may compile or group data that are related (such as data that isrelated to and/or may affect the cost of a trial). The augmentingcomponent 124 may group data and determine relative scales or values forthe data (such as 1-10 scale for complexity). The grouped and scaleddata may be identified with tags or other identifiers for matching withreal-world data during the substitution and/or supplementing process.

Accordingly, referring now to FIGS. 26 and 27, in embodiments, theapparatus 2700 may include a simulated output processing circuit 2710structured to interpret/obtain 2610 a simulated output dataset 2712 of aclinical trial design. In certain aspects, the simulated outputprocessing circuit 2710 may be in communication with (or integratedwith) a network interface card, wherein the simulated output dataset2712 is received over a corresponding network connection. The simulatedoutput processing circuit 2710 may transform the simulated outputdataset 2712 from a network transportation format into a differentformat suitable for use by the various circuits in the apparatus 2700.For example, the simulated output dataset 2712 may be received by thesimulated output processing circuit 2710 as a series of packets, whereinthe simulated output processing circuit 2710 may reassemble the packetsinto a complete data structure. In embodiments, the simulated outputdataset 2712 may be distributed across multiple databases. In certainaspects, the simulated output dataset may include relative data and/orgeneral data.

The apparatus 2700 may further include a supplemental processing circuit2714 structured to interpret/obtain 2612 supplemental data 2716.Non-limiting examples of supplemental data include: costs of a clinicaltrial; time to completion of a clinical trial; NPV of a clinical trial;actual personnel costs of a clinical trial; or actual facility costs ofa clinical trial. In embodiments, the supplemental data 2716 may bederived, e.g., collected, from one or more clinical trial sites 144. Theapparatus 2700 may further include a relation determining circuit 2718structured to determine 2614 a relationship 2720 between the simulatedoutput dataset 2712 and the supplemental data 2716. Non-limitingexamples of relationships include related units, related data tags,timestamps, user defined relationships, semantic analysis, and/or thelike. In certain aspects, the relationship 2720 may be based at least inpart on metadata, labels and/or unit values. The apparatus 2700 mayfurther include a supplemental data modification circuit 2722 structuredto generate 2616 modified supplemental data 2724 based at least in parton the relationship 2720. Non-limiting examples of modified supplementaldata include financial data, regulatory data, revenue data, and thelike. The apparatus 2700 may further include a substitute circuit 2726structured to generate 2618, based at least in part on the modifiedsupplemental data 2724, substitute data 2728 of/for the simulated outputdataset 2712. Non-limiting examples of substitute data 2728 may includecosts, time, number of personnel, available sites, number of enrolledpatients, and/or the like. The apparatus 2700 may further include asubstitute data provisioning circuit 2730 structured to transmit 2620the substitute data 2728. The substitute data provisioning circuit 2730may be in communication with, or integrated into, a network interfacecard that communicates with one or more remote devices via a network.The substitute data provisioning circuit 2730 may format the substitutedata 2728 into a network specific format.

In certain aspects, the apparatus 2700 may further include a graphicaluser interface circuit 2732 structured to generate graphical userinterface data 2734 for generating a graphical user interface thatfacilitates user control over augmentation of the simulated data. Assuch, the apparatus 2700 may further include a user input dataprocessing circuit 2736 structured to interpret user data 2738 enteredinto the graphical user interface. For example, the graphical userinterface may provide for the user to enter the supplemental data 2716and/or provide instructions to the apparatus 2700 as to where and howthe supplemental data 2716 may be acquired, e.g., downloaded from remotedatabases.

In embodiments, the substitute data 2728 may be used to replacecorresponding parameters that were used to generate the simulated outputdataset 2712 so that new simulations can be executed/run with moreaccurate data. In certain aspects, the substitute data 2728 may beincluded in one or more reports and/or displays, e.g., via the graphicaluser interface provided by the graphical user interface circuit 2732.For example, the graphical user interface may depict differences betweenthe simulated output dataset 2712 and the substitute data 2728. Inembodiments, the graphical user interface may depict differences betweenthe simulated output dataset 2712 and an updated simulated outputdataset derived from re-running the clinical trial design simulations,used to generate the simulated output dataset 2712, with the substitutedata 2728.

As will be appreciated, use of supplemental data 2716, as describedherein, may provide for improved accuracy with respect to simulatingclinical trial designs. Further, by providing for the ability to augmentsimulated outputs, embodiments in accordance with method 2600 and/orapparatus 2700 may provide for earlier planning of a clinical trial, aspossible clinical trial designs can be first simulated with estimateddata, thus enabling other planning processes to begin and/or proceed,with the simulated data being adjusted based on real data at a laterpoint in time.

In some embodiments the simulation models may include various parametersand data that are used by simulation engines to evaluate designs. Modelparameters may be separated into different categories. Model parametersmay be separated based on delineated expertise of teams. In some cases,members of a team may have different specializations. For example, somemembers may specialize in building human behavior models, while othersmay specialize in trial design models. Separating or grouping theparameters may allow different team members to independently optimizeand improve specific aspects of models. In some embodiments, the modelparameters may be separated into two or more types based on convenience,expertise, flexibility, and the like. Separation of parameters mayprovide for new and faster methods for simulation, analysis,optimization, and the like when the separation of parameters is at leastpartially maintained and propagated through the simulation and analysiscomponents of the platform.

In embodiments, model parameters may be separated into at least twotypes or categories. Model parameters may be grouped to includeparameters that define the trial design space and clinical scenariospace. The trial design space may include one or more parameters thatare related to protocol design, dosing algorithms, subject selection,demography, blinding of subjects, measurements to be performed, studylength, and the like. The trial design space may include one or moretrial design types with a combination of design variables. The trialdesign may specify how data will be analyzed. The design space mayfurther include deviation models for one or more of the parameters ofthe design models. Deviation models may be based on expected orpreviously measured distributions or variations in the design.

Trial design space may further include experimental design data,adaptation rules data, and analysis model data. The experimental designdata may include data, parameters, variables, and the like related tosample size, number of sites, accrual durations, allocation ratio, andthe like. The adaptation rules data may include data, parameters,variables, and the like that specify the number of interim analyses, thetiming of the interim analyses, boundaries, and the like. The analysismodel data may include data, parameters, variables, and the like thatspecify test statistics, type one (1) error, and the like. Inembodiments, each data, parameter, variable, and the like may have a setand/or a range of acceptable, realistic, or practical values. Inembodiments, a set of trial designs may be generated wherein each trialdesign may have a different combination of data, parameters, variables,and the like. In some cases, the combination of different possible datavalues, parameters, and/or variables may result in thousands or millionsof different trial design options.

Scenario space may include environmental and external factors that mayaffect trial design. In some embodiments, scenario data may include oneor more mathematical or numerical models and methods that are relatedand/or describe one or more of human behavior, disease progress, drugbehavior, and the like. Scenarios may include a combination ofenvironmental variables that provide a specification or guidelines forgenerating virtual patient populations for a design study. Humanbehavior inputs may include trial execution characteristics, includinghow subjects adhere to regimen, dropout rates, and the like. Drugbehavior may include models of drug behavior in a body and may includepharmacokinetic and pharmacodynamic models. The inputs may furtherinclude deviation models for one or more of the parameters of themodels. Deviation models may be based on expected or previously measureddistributions or variations in aspects such as human behavior,demographics, and the like. In embodiments, a plurality of differentscenarios may be generated as potential inputs to the platform whereineach scenario may include different aspects of human behavior, diseaseprogress, and drug behavior, and the like.

In embodiments, simulation models may be generated by combining two ormore categories of inputs, such as by combining design space andscenario space. In embodiments, design space and scenario space may bedefined separately and combined to generate models that include the twospaces. Generating the models from the two spaces may involve generatingpermutations of the two spaces. In one embodiment, a cross productbetween each scenario in the scenarios space and each design in thedesign space may be used to generate models. In this configuration, alarge number of models may be generated from a much smaller set ofdesigns and scenarios. In embodiments, millions of models may be createdfrom design and scenario spaces that correspond to only thousands ofdesigns and scenarios.

In some embodiments, the trial and clinical spaces models may beselectively combined, such that some instances of trial designs andclinical scenario models are not combined to create simulation models.The selective combination may reduce the number of simulation modelsthat are simulated by the system, thereby reducing computation time. Insome embodiments, a variety of heuristics, algorithms, filters, and thelike may be used to select a subset of all possible combinations oftrial and scenario spaces to reduce the number of simulation models,eliminate improbable combinations, and the like. In some embodiments,models may be scored before they are simulated. The scoring may bebased, at least in part, on the feasibility, probability, practicality,or the like of the scenario-design combination for each model.

In embodiments scoring may be based on rating and/or priority associatedwith the design space parameters and/or scenario space parameters ineach model. Ratings and/or priority may be provided by a user and/orother parts of the system. In some embodiments, rating and/or prioritymay be determined from historical data from previous simulations anddesign studies. The ratings and/or priority may be determined based onthe number of occurrences of the parameter in the historical data insimilar designs studies. In some embodiments the ratings and/or prioritymay be determined on the number of occurrences of the parameters indesigns that were identified as optimal or desirable in previous designsstudies. Ratings and/or priority score may be used to determine arelevancy score. The relevancy score may be computed as function of theratings and priority score such that the higher the ratings and/orpriority score the higher the relevancy score. Models that score below athreshold may be flagged or removed such that they are not simulated.

After the simulation models are created, the platform may execute andevaluate the simulation models. In embodiments, each simulation model(i.e., a specific combination of a trial design and scenario) may beevaluated over the course of numerous simulation runs, and the number ofsimulations may vary depending on the project stage. Each simulation runmay be based on a different deviation of the trial design and/orscenario according to the respective deviation models. Results frommultiple simulation runs for a particular simulation model may beanalyzed to determine performance parameters.

In embodiments, results of simulations may be organized and groupedaccording to their relation to design and scenario space. Performanceparameters of each model after simulation may be grouped to showrelations of each parameter to one or more aspects of a design and/orscenario models. The relations may be used to refine aspects of thedesign space and/or scenario space for additional evaluation.

Referring to FIG. 28, a flow chart for the evaluating designs mayinclude defining design space 2802 and scenario space 2804. The designspace and scenario space may be used to determine combinations 2806 thatare used to define models 2808 for simulation 2810. The combinations maybe analyzed by one or more filtering components 2814 that may rate andrank the combinations. The simulation data may be analyzed to determinedesirable and/or optimum designs. Based on the analysis, the designand/or scenario spaces may be modified to generate more combinations forsimulation.

As shown in FIG. 29, a method for evaluating designs may includeobtaining a design space 2902 and a scenario space 2904. The set ofsimulation models may be generated by combing different permutations ofthe design space and scenario space 2906. The simulation models may bescored and filtered 2908. The method may further include simulating thefiltered set of simulation models 2910 and analyzing the simulationresults 2912.

In embodiments, simulations may require population models to evaluate adesign for virtual subjects. Population models may definecharacteristics of subjects in a clinical trial. A trial design maydefine aspects of subjects that should be included in a trial. A trialdesign may define inclusion and exclusion criteria for subjects based oncharacterizations of demography, disease status, and the like.

In embodiments, for a simulation, virtual subjects may be selected frompopulation models. A population model may include subject models thatinclude various subject characteristics such as demography data,survival models (control and treatment), dropout rate (control andtreatment), expected responses, and the like. Characteristics ofsubjects in a population model may be associated with differentdistributions. The distributions of parameters of the population modelmay correspond to real-world population models. In embodiments, when asubject is included in a simulation, a population model may be evaluatedto determine characteristics for a subject for one simulation instance.For each simulation instance, the population model may be evaluated(with a random value for selection) to identify a new subject and thesubject may be selected based on inclusion/exclusion criteria of thetrial.

In embodiments, a virtual population may be pre-generated. The virtualpopulation may be generated according to a population model and/orreal-world population data. The virtual population may be a list orother data structure that includes thousands or even millions ofdifferent virtual subjects. Each subject in the virtual population maybe associated with characteristics such as demography data, survivalmodels, dropout rate, expected responses, and the like for each subject.For a simulation, a subject may be selected from the virtual population(randomly or based on another function) for simulation of a trialdesign.

FIG. 30 shows aspects of utilizing virtual populations for simulation. Avirtual population 3002 may be generated from population models 3006and/or from real world population data 3004. The virtual population 3002may include data representing individual subjects (virtual patients) andcharacteristics of the subjects. The virtual population may be generatedto have a specific distribution of characteristics for the subjects. Thedistribution of characteristics may be consistent with real-world datafor a specific population or sub-population. The virtual population mayinclude data for hundreds, thousands, or even millions of subjects. Insome embodiments, multiple different virtual populations may begenerated with different distributions of characteristics for thesubjects.

In embodiments, a virtual population 3002 may be pre-generated beforesimulation start or may be generated in real time during simulation. Insome embodiments, subjects may be generated as they are needed and/orrequested for simulation using population models and the subjects may beadded to a virtual population each time it is generated. The virtualpopulation may grow as simulations and analysis of designs progresses.The virtual population may be a data structure (such as a database,list, table, and the like) that may be configured to retrieve data for asubject or a group of subjects randomly, according to specific subjectcharacteristics, according to an unique identifier of the subject, andthe like. Subjects in the virtual population may be used for simulationof trials. Simulation instance 3014 may include characteristics of asubject. The subject for the simulation may be selected from the virtualpopulation 3002. A simulation instance may evaluate a design for thesubject for a specific design and scenario combination 3014. Simulationsmay include a plurality of simulation instances 3014, 3016, 3018 usingdifferent subjects from the virtual population and variations of designand scenario combinations 3008, 3010, 3012.

In embodiments a subject for a simulation instance 3008 may be selectedfrom the virtual population 3002 randomly, based on a function of thecharacteristics of the subjects, by a unique identifier associated witheach subject, and the like. In embodiments, each simulation instance maybe associated with a unique identifier of a subject used for simulation.The virtual population may be used for all simulations of a study.Simulations instances may be reproduced with the same subject from thevirtual population by saving a unique identifier associated with thesubject with the simulation instance in a simulation history record.

In embodiments pre-generated virtual populations may have severalbenefits over subject selection from a population model. Subjectselection from a virtual population may decrease computation time sincea population model does not need to be evaluated for simulation instanceand requires a simpler selection from a population (such as a selectionfrom a list or table). Virtual populations provide for enhancedreproducibility given a constant population and improved accuracy ofresults across multiple simulations given constant population. Inembodiments, due in part to the reproducibility aspects, pre-generatedvirtual populations may enable easier and faster computations ofcounterfactual data.

In embodiments, simulations may include determination of counterfactualdata for a trial. Counterfactual data may relate to data that would havebeen observed under different (often conflicting) configurations of atrial. For example, if a trial provides data about an outcome of apatient that receives a therapy, counterfactual data may be data thatrelates to an outcome of the same patient if they did not receive atherapy. Normally, counterfactual data cannot be observed in areal-world trial. Continuing with the example, a patient, in areal-world trial can receive a therapy or not receive a therapy, but notboth since the two configurations are conflicting. In a real-worldtrial, a patient can only be in one of two groups and therefore only onepossible configuration of trial can be observed. The data related to aconfiguration that is not observed by a trial may be counterfactualdata.

In another example, a trial may have missing data when patients drop outof the trial. The missing data is the data that would have been observedhad the patient not dropped out of the trial. Missing data cannot beobserved in a real-world trial but may be determined using simulation.Missing data (which may be a type of counterfactual data) may bedetermined by simulating a trial design configuration for when a patientdrops out of the trial and a configuration where the same patient doesnot drop out of the trial.

A trial design simulation may determine what is expected to happen in atrial and what could have happened in a trial given a differentconfiguration (such as counterfactual data). Counterfactuals may be usedto determine estimands for a true effect of a treatment. In embodiments,counterfactual data may be used to determine how good a trial is atestimating the estimands of interest using the observables of a trial.In embodiments, estimands determined from counterfactual data may beused to configure a trial design parameter (such as population size) toenable a trial design to come close to estimating the estimands.

FIG. 31 shows aspects of a platform that utilizes counterfactual data ina simulation. In embodiments, simulations may include simulations 3114,3116, 3118 to determine what is expected to happen in a trial 3134 andanother set of counterfactual simulations 3120, 3122, 3124 to determinewhat could have happened in a trial given a different configuration. Forexample, one simulation 3114 may simulate an outcome if patient Areceived a treatment and another counterfactual simulation 3120 maysimulate an outcome if patient A did not receive a treatment. Inembodiments, the trial data 3134 may be used to determine the estimator3136 of a design. In embodiments, the trial data 3134 may be compared tothe counterfactual data 3132 to determine estimand for the trial 3138. Aperformance of a trial may be evaluated as to how close the estimator oftrial is to the estimands. A trial for which the estimator is close tothe estimands may be considered desirable.

As shown in FIG. 32, a method for evaluating designs with counterfactualdata may include simulating a configuration of a trial design todetermine trial data 3202. The method may further include simulating asecond configuration of a trial design to determine counterfactual data3204. The trial data and the counterfactual data may be compared todetermine an estimand for an outcome of the trial 3206. The method mayfurther include determining, for the outcome of the trial, the estimatorof the trial design 3208, and scoring the design based on a distance ofthe estimator to the estimand 3210.

As shown in FIG. 33, a method for evaluating designs with counterfactualdata may include determining observable data for a trial 3302. Themethod may further include determining counterfactual data for a trialdesign 3304. An estimand may then be determined from the observable dataand the counterfactual data 3306. The method may also includedetermining, from the observable data, the estimator for the design3308. The design may be modified or other variations of the design maybe explored (such as a design with a different population) such that thedifference between the estimator and estimand are within a threshold3310.

FIG. 34 shows aspects of an apparatus for evaluating design withcounterfactual data. In embodiments, the design evaluation circuit 3402may receive simulation data from a simulation circuit 3412 andcounterfactual simulation data from a counterfactual simulation circuit3410 the data may be for a design. An estimand determining circuit 3404may be configured to determine an estimand for an outcome using theinput data. An estimator circuit 3406 may be used to determine theestimator for the design. An evaluation circuit 3408 may be configuredto determine how well the estimator estimates the estimand. A distancemeasure, such as a difference or other statistical measure may bedetermined. Based on the measure the design may be scored and the designevaluation circuit 3402 may output a design score parameter 3414 basedon the difference.

Interactive methods can be used in the process of evaluating designs,conducting simulations, configuring a design study (such aspre-simulation)s, and the like. Interactive methods may be methods inwhich a person or an alternate algorithm acts as a decision-maker andinteracts with the methods, systems, and platform to indicate apreference for aspects of the outcomes and/or input. The preferences maybe used to determine other inputs and/or outputs that relate to thepreferences.

In embodiments, interactive methods may be used to identify preferencesfor trial designs. The preferences in trial designs may be used toidentify optimum designs based on the preferences. The preferences intrial designs may be used to identify other designs that are similar tothe preferences, surface design options that are complementary to thepreferences, determine ranking of desired aspects of designs, determineunwanted features, and the like.

In embodiments, interactive methods may include providing a comparisonand tracking selections in response to the comparison. In embodiments,configuration parameters may be presented to a user. Aspects of criteriaspace, design space, scenario space, and performance space may bepresented before simulation. Parameters may be presented as a comparisonbetween different parameters and/or values of the parameters. User inputmay an interaction between the values or parameters shown. Interactionsmay be used to identify preferences for parameters and/or values forparameters.

In embodiments, results of simulations may be presented to a user.Performance of simulated designs may be presented to a user via aninteractive interface. In one embodiment, the interactive interface maypresent results of simulations as a comparison between two or moresimulated designs. User input may include a selection of a preferencebetween the designs, saving of one or more of the presented designs,indicating an interest in one or more parameters of the design and thelike.

Interactive interfaces may be used to present two or more performanceparameters of a simulated design to a user. In one embodiment the usermay specify a preference for a design. Based on the tracking of theselection, one or more user preferences may be determined. Userpreferences may be identified from the user selecting a design, saving adesign, dismissing a design, moving a design, and the like. Inembodiments, preferences may be determined by identifying differencesbetween the presented designs the designs associated with a user action.

In some embodiments, designs presented for consideration in aninteractive interface may be selected based on results of optimalitydetermination based on Pareto analysis and/or CH analysis. In someembodiments, designs presented for consideration in an interactiveinterface may be selected randomly from the set of designs.

Designs presented for consideration in an interactive interface may beselected such that an interaction with of one or more design in theinterface provides useful information about preferences of a user.Designs may be selected for presentation may be selected such that theyare substantially similar is most parameters and different with respectto a small number of parameters (such less than 10). Havingsubstantially similar designs for comparison may provide a clearindication which parameters and/or values are preferable to a user whenan interaction with the designs is observed. In embodiments, designs maybe selected such they represent very different designs. The designs mayrepresent different ends of the spectrum with respect to the overalldesign (designs may differ in more than 10 parameters). Having designsthat represent vastly different designs for comparison may provide aclear indication of the overall properties and types of designs that arepreferred.

In embodiments, information inferred from interactions may be directlyrelated to the parameters and values for which interactions werereceived. In some embodiments, information inferred from interactionsmay be derived for parameters and values for which interactions werereceived. Interactions related to one parameter or a design may provideadditional information about other parameters. For example, interactionsrelated to cost of a study may be used to determine preferences for thecost and/or other related parameters such a duration (longer studies maytypically be more expensive), number of patients (more patients mayrequire more sited and more cost), and the like.

In embodiments, interactive interfaces for identifying preferences fordesigns may be iterative and may require multiple interactions from auser to determine preferences. In the case of an interactive interfacebased on a comparison, the interface may iterate over multiple cycles ofpresenting designs and receiving user selections. In each iteration, theinteractive interface may present a different set of designs forconsideration and monitor user interactions with the designs. In eachiteration, the set of designs may be strategically selected to determinedifferent aspects of preferences from user interactions. For example, infirst iteration the designs shown on the interface may be selected toidentify preference for design type, in the second iteration, thedesigns may be selected to identify preference for a first parameter.

Once preferences are identified designs, such as optimal designs, may bedetermined for the preferences.

In embodiments, interactive methods may be used to identify regions ofinterest and/or identify additional designs for simulation. Initialsimulations may be coarse grained simulations. Coarse grainedsimulations may not be exhaustive but may be used to provide a coursegrid of designs that provides an overview of the designs and performancefor identified criteria by simulating subset of the possiblecombinations. Some of the simulated designs from the coarse set ofsimulations may be presented to a user. User interactions with thepresented designs may be used to identify types of designs andparameters of the designs that may be further explored with simulation.

In embodiments, an interactive method for identifying regions ofinterest may include an interface such as a map that shows relativeand/or absolute performance of designs and their parameters. Theinteractive interface may be used to visualize the locations of designsin the performance space. Users may select regions of interest and theplatform may be directed to identify designs that may be in the regionsof interest for further simulation and evaluation.

In embodiments, an interactive method for identifying regions ofinterest may include an interface that identifies one or more designsfrom the coarse grid of designs. The designs and the properties andperformance of the designs may be presented to a user and the userinteractions with aspects related to the design may be tracked. Based onthe interactions, user preference for the design may be determined.Additional designs may be presented to the user to determine preferencefor additional designs. Based on the interactions and preferences fordesigns, a region or an area in the design space may be identified asbeing an area of interest. An area of interest may include an areaaround a design (such as all designs within an ε-distance of a design).An area of interest may be an area between two designs. An area ofinterest may be an area bounded by three or more designs (such as atriangular area bounded by three designs). The area of interest may beused as a guide for additional simulations. Additional simulations maybe conducted on the designs that are in the area of interest.

In embodiments, interactive interfaces may be in connection withsensitivity analysis of designs. Interactions with the interface may bemonitored to determine preferences for designs with respect tosensitivity and/or robustness of the designs. User interactions withinterfaces for interacting with graphical elements for specifyingfilters, designs, regions, and the like may be tracked to determinewhich aspects of a design the user analyzes the most with respect tosensitivity of the design. The interactions may be tracked to determineminimum and/or maximum acceptable values for one or more parametervariations.

In embodiments, user interactions with interactive interfaces may berecorded and saved. In some embodiments, interactions with interactiveinterfaces may be processed to derive relevant data from the interactionand only the derived relevant data may be stored. In some embodiments,the derived data and the raw interaction data may be stored. Aspects ofpresented data in the interactive interfaces, interactions from users,sequence of interactions to achieve an outcome, and other aspectsrelated to interactive interfaces may be saved. Interactions data, alongwith design data, design data, scenario data, and the like may be usedto train one or more AI and/or ML models for identifying userpreferences from interactions. The models may be trained on the previousinteractions, presented data, and other aspects of the design studyrelevant to the interaction such as the criteria space, design space,scenario space, and performance space definitions. The trained modelsmay be used to predict which designs should be presented to the user tomaximize information obtained from the interactions from the user withthe presented designs. The models may be trained to determine userpreferences based on the interactions and the final selections. The useof trained models may reduce the number of iterations and amount ofinteractions that need to be observed to identify preferences and/oridentify other designs or regions of interest.

As shown in FIG. 35, the interfaces component 3502 may include componentfor generating visualizations 3504. The visualizations may include datarelated to simulated trial designs 3510. The visualizations may presentdata related to trials and receive user input data 3512 that isindicative of user interactions with the interface and the presenteddata on the interface. The apparatus may include a feedback analysiscomponent 3506 for tracking and analyzing the user input andinteractions 3512. The feedback analysis component 3506 may analyzeinteractions to determine design preferences, regions of interest, andthe like. In some embodiments, the feedback analysis component 3506 mayreceive data related to user interactions which may include AI/ML modeltrained on the previous interaction data 3508. The feedback analysiscomponent 3506 may determine preferences 3514 for designs, parameters ofdesigns, regions of interest 3516 for designs and the like based on theinteractions.

FIG. 36 shows aspects of an apparatus for determining preferences fromuser interactions. In embodiments, the interfaces circuit 3602 mayinclude a user input circuit 3604 and a simulation results processingcircuit 3606. The user input circuit 3604 may process interaction data3612 from a user. The interaction data 3612 may relate to userinteractions with data and components of an interactive interface. Theinterface may, during the interaction, display design data that isreceived from a recommendation circuit 3610. The simulation processingcircuit 3606 may further include a criteria determination circuit 3608that may be configured to analyze processed user interaction data fromthe user input circuit 3604 and data provided in the interface from thesimulation results processing circuit 3606 and determine userpreferences. The preferences may include design preferences 3614 and/orregions of interest 3616.

As shown in FIG. 37, a method for determining design using userinteractions may include obtaining trial design simulation results froma set of trial designs 3702 and recommending a first subset of trialdesigns to a user 3704. The recommendations may be via one or moreinteractive graphical interfaces. The method may include receivingfeedback from the user via the interface 3706. The feedback may includeinteraction data that relates to one or more of the recommended designs.The method may further include identifying characteristics of trialdesigns preferred by the user from the feedback 3708. Using thedetermined characteristics, the method may determine new trials with theidentified characteristics that have not been presented to the user3710. The new trials may be simulated 3712. The method may be repeatedat least some of the recommended designs being the new simulateddesigns.

Shown in FIG. 38 is a method for determining a design using userinteractions. The method may include obtaining trial design simulationsresults for a set of trial designs 3802. The method may further includeproviding a first subset of trial designs to a user 3804 and feedbackfrom the user may be received from an interface 3806. Based on thefeedback, one or more regions of interest from the design space may beidentified 3808. The method may further include identifying a second setof trial designs that are within the region of interest 3810.

In embodiments, the interactive graphical interfaces may include a cardinterface. A In embodiments, a card interface may be used to evaluate ordetermine aspects the criteria space, design space, scenarios space,and/or performance space.

In embodiments, a card interface may be used to evaluate simulateddesigns. The card interface may be configured to identify, based on userinteractions with the interface, user preferences for designs,preferences for design parameters, optimality of designs, and the like.The card interface may be configured to identify, based on userinteractions with the interface, regions or areas of interest in thedesign space that appear to have desirable designs. These areas may befurther explored with further simulations and analysis.

In embodiments, the card interface may include depictions of elementsreferred herein as “cards” that represent one or more of the simulatedtrial options. Depictions of cards may include rectangular shapes thatmay group data or parameters associated with a simulated design. Thecards may be depicted as rectangles, squares, circles, polygons, orother shapes. The graphical interface depicting cards may include one ormore cards that are associated with different trial designs.

In embodiments, an initial set of cards may be populated on thegraphical interface, such as when simulations are completed. In someembodiments, an initial set of cards may be populated on the graphicalinterface during the simulation before all of the simulations arefinished based on available or intermediate data. A card may provide anintuitive grouping of data for a trial design allowing a user to easilydetermine the parameters and qualities of the trial design the card isassociated with.

In many situations, the number of simulated trial designs may be largesuch as a thousand or even millions of simulated trial designs. Inembodiments, the number of cards shown on the graphical interface may beless than the number of simulated trial designs. In some embodiments,the number of cards initially shown on the interface may be less thanfifty (50) or may be less than ten (10). The number of cards initiallyshown may be determined based on the total number of simulated trialdesigns, a user preference, historical preference, or the like.

A number of cards may be initially shown on the interface. Each card maybe associated with and show data related to a particular trial design ofthe set of simulated trial designs. The selection of the initial trialdesigns that are represented by the cards may be selected using aninitial card selection criteria.

In some embodiments, the initial card selection criteria may be a randomcriteria wherein random trial designs from the set of simulated trialdesigns are selected. In some embodiments, the initial card selectioncriteria may be based on a selection of trial designs that have the bestvalue for one or more parameters. In some cases, each card shown on theinterface may represent a trial design that has a maximum value for adifferent parameter. In embodiments, initial cards shown may representthe trial design that is associated with the trial design that has thebest value for each strategic goal. Depending on the parameter, the bestvalue may be the maximum value, a minimum value, a median value, and thelike and may depend on the parameter and the goals of the parameter.

In some embodiments, the initial card selection criteria may be based atleast in part on historical data (such as associated with a particularuser or organization). Trial designs may be selected that have similarparameters to trial designs that were ultimately selected or werefinalists in other clinical trials.

In embodiments, the selection of trial designs for cards may be based ona function of one or more parameters and variables. In some embodiments,the selection of trial design candidates for cards may be based on aweighted value sum of one or more parameters and variables. Theweighting may be based on a specific goal of the study or other designparameters or requirements. In some cases, two or more differentfunctions may be used. In some cases, each card or some cards may beassociated with a different selection function. In embodiments,selection of trial designs for cards may be based on Pareto and/or CHanalysis. Pareto designs and/or CH-designs may be used to populate datain the cards.

FIG. 39 shows one embodiment of a graphical interface with cardsassociated with trial designs. The figure shows four cards elements3902, 3904, 3906, 3908 with each card showing seven parameter values ofdifferent trial designs. In this case, the four initial cards representa trial design that has the best value for four (4) different strategicgoals. The first card 3902 is representative of a trial design thatmaximizes the expected net present value (eNPV) of all the simulateddesign studies. The first card 3902 shows parameters of the trial designthat maximizes the eNPV for the simulated trial designs. Other cards arerepresentative of trial designs that maximize or minimize other designgoals, such as the probability of success (POS), discounted cost, andstudy duration.

In embodiments, colors, shading, saturation, background color, and thelike may be used to represent information regarding values of theparameters of a trial design shown on each card. In embodiments colors,shading, saturation, background color, and the like may be used torepresent the relative value of a parameter with respect to all of thesimulated trial designs. For example, a low relative value may be shownwith a blue color, while a large relative value may be shown with a redcolor. In embodiments, colors, shading, saturation, background color,and the like may be used to represent the relative value of a parameterwith respect to the values shown on the cards.

In embodiments, the graphical card interface may include designs forspecifying filters 3910 for one or more parameters of the trial designs.Filters 3910 may affect which trial designs are displayed by the cards.In embodiments, the filters may affect the number of cards shown.Filters may be used to set global limits on specific parameters for allthe displayed cards or may be applied differently to each card.

In embodiments, filters may be applied to cards that are configured todisplay cards that maximize or minimize a strategic goal. An appliedfilter may cause the card to display a trial design that provides themaximum or minimum for a strategic goal but also satisfies the bounds ofthe filter.

In embodiments, filters may be applied via one or more graphicalcontrols. The controls may be different based on the type of parameteror variable the filter is being applied to. Parameters or variables thathave real numbers, for example, may have different controls thanparameters or variables that have Boolean values. In some embodiments,the filter controls may include sliders, dials, input boxes, and thelike. The behavior of a control may depend on the values for therespective parameters or variables in the set of simulated trialdesigns. The behavior of the control may depend on the distribution ofthe values of the respective parameter or variable. For example, in thecase of a slider control, the behavior of the slider control may benonlinear with respect to the value the slider represents with respectto the position of the slider. The behavior of the slider may bedifferent when the slider is in a position where there are many valuesfor a variable or a parameter versus where there are no values for avariable or a parameter.

In embodiments, filter settings may be analyzed with respect to the oneor more distributions, values, desired values, expected values, goals,trial goals, trial parameters, trial values, distribution of values,distributions or parameters, and the like. Filter settings may beanalyzed to determine how adjusting one or more filters may impact whattrial designs are displayed on one or more cards. For example, filtersettings may be set to filter out all trial designs below a specificvalue of a parameter of the trial designs. However, the setting of thefilter may filter out many trial designs that meet one or more strategicgoals. In embodiments, the sensitivity of filter settings may beidentified, and their sensitivity may be communicated to a user. Inembodiments, a user may be provided with information to indicate thatthe user may consider adjusting one or more filter settings. The usermay be provided with information as to how the settings may be changed.In some embodiments, the platform may adjust filters when the filtersare determined to be too aggressive or determined to cause filtering oftrial designs that would otherwise be good candidates for a trial orthat a user should otherwise review. In some embodiments, the filtersmay be set to approximate values, and the platform may be configured toautomatically set the filters to an actual value based on analysis ofthe trial designs and/or design objectives.

In some embodiments, filter settings may be analyzed with respect to adistribution of the values related to the filter. Users may be providedwith information regarding the setting of the filter with respect to thedistribution of the values. For example, in some cases, a variable mayhave a binomial distribution. The user may be provided with informationregarding the setting of the filter and how the setting may be adjustedto consider a cluster or a specific distribution of values. In somecases, filters may be associated with one or more graphs or graphicsthat identify the distribution of the values associated with the filter.In some cases, a user may be provided with a graph or other indicatorsthat provide information about the relation between a value associatedwith a filter and one or more strategic goals.

In embodiments graphics on a displayed card, around a displayed card,the like may provide additional information regarding the trial designdisplayed compared to other simulated trial designs not displayed.Graphics may be used to provide information regarding how many othertrial designs are within a specified distance to the displayed trialdesign. Graphics such as variable shadows, lines, colors, and the likemay provide a quick visual indication as to the number of similar trialdesigns are available to the trial design displayed on the card. Inembodiments, graphics may indicate a depth of a deck of cards, thenumber of trial designs related to a card, the number of trial designsin the same category as a card, and the like.

In embodiments, cards in the card interface may be manipulated by auser. User interactions with the card interface may be tracked.Interactions may include manipulation of cards. Manipulation of cardsmay include actions that are performed by a user in the process ofexamining and selecting one or more trial designs. Manipulations mayinclude selecting, ranking, moving, putting into a “shopping cart” or“favorites” category, comparing, and the like. The manipulations of thecards may be tracked by the platform to determine the preferences and/orgoals of the user.

In embodiments, the platform may use the history of the interactions,such as the manipulations, to provide suggestions for filter settingsand/or provide new cards that show additional trial designs forconsideration. For example, the platform may identify a trend that cardswith data related to trial designs with a cost exceeding a specificvalue are removed from consideration by a user. The platform may use theidentified trend to determine additional trial designs below the costand provide the designs for consideration to the user.

In embodiments, data related to objectives of an organization,historical data, customer data, and the like may be used to identifytrial designs automatically. In embodiments, the automaticallyidentified trial designs may be displayed to a user with a card forconsideration. In embodiments, manipulation of cards may be used toidentify preferences such as absolute values or variables or parameters,relative values, and correlations. In embodiments, the platform may findtrial designs that are similar to those selected as “favorites” andpresent them as cards for consideration.

In embodiments, cards that were tagged as a favorite, saved in ashopping cart, or highly ranked by a user may be selected for display ina comparison table. Data related to the trial designs of the cards maybe displayed in a table format, and the data may be compared by the useror exported for comparison or other purposes. In embodiments, theinterface may include visual effects such as highlighting or emphasized(such as a darker border, a different color of border, a flickering ofcolors, and the like) to confirm user interactions and/or providefeedback that an interaction was analyzed to determine preferences.

In embodiments, the platform may determine preferences forcharacteristics of trial designs by presenting various trial designs inthe form of cards for considerations. The trial designs may bestrategically selected to explore preferences between tradeoffs betweenone or more parameters. In some embodiments, cards with selected valuesmay be presented to a user allowing the user to select the card orprovide other indications of interest in the card. Based on theresponses, the platform may determine which variables or parameters areimportant, as well as acceptable ranges for those variables andparameters. In another embodiment, the platform may simultaneouslypresent two or more cards with contrasting values for parametersallowing the user to choose a favorite card or rate the relativeinterest in the cards. Based on the rating and selection, the platformmay determine which parameters, variables, values, and the like the useris most interested in or that are more important to the trial. Cardspresented to the user may reflect values of specific trial designs ormay not be selected to explore preferences and may not be directlyrelated to any specific trial design.

In embodiments, the platform may determine preferences forcharacteristics of trial designs by presenting various combinations ofparameters. The platform may show parameter values that represent cornercases of one or more parameters. The platform may show values thatrepresent a spectrum of values of one or more parameters or acombination of parameters to determine a user preference. For example,the platform may display cards to a user that represent different rangesof parameters such as a high cost or low cost. Based on userinteractions with the cards, the platform may determine a user'spreference for cost. In another example, the platform may determine userpreferences for a tradeoff between parameters by presenting cards withtwo or more parameter values. For example, the user may be presentedwith one card that represents high cost and low time values. The usermay be further presented with another card that represents low cost andhigh time values. Based on user selection of the cards, the platform maydetermine the user preferences for tradeoffs between cost and time for astudy.

In embodiments, the platform may determine a trial design through one ormore processes that may use various graphical interfaces for determininguser preferences, user selections, refining results, receiving feedback,and/or the like. In some embodiments, a series of scripts, programs,algorithms, and wizards may analyze data, patterns in the data, userpreferences from the data, and/or the like without direct or other useof a graphical user interface. In some embodiments, any combination ofdata analysis and graphical user interfaces may be used to narrow down aset of trial designs to one or more selected trial designs.

In embodiments, one or more, artificial intelligence algorithms, neuralnetwork, statistical analysis, and the like may be used to track userselections, analyze the history of trial design selections to suggestone or more filters and trial designs in view strategic goals,preferences, constraints, and the like.

As shown in FIG. 40, a method for evaluating designs with userinteractions in a card interface may include presenting a set of cardswherein each card is representative of a different trial design 4002.Each card may include graphics that display one or more parametersassociated with the card. The designs represented by the cards may bederived by Pareto analysis, CH analysis, and/or simulated annealing. Thedesigns presented by the cards may be selected at least in part based onfilters. In embodiments, filters may be configured by user input toselect bounds and/or values on one or more parameters. The method mayfurther include monitoring user interactions with the cards 4004.Interactions may include selecting cards, moving cards, deleting cards,saving cards, changing filters, adjusting filter, and the like. Based onthe interactions, the method may determine preferences for one or morevalues and/or parameters of designs 4006. The method may further includepresenting at least one new design based on the determined preferences4008. The new design may be presented on a new card that is added to theset of cards. The new design may be shown as a replacement for apreviously shown design. The method may further include monitoring userinteractions with the cards that include the new design 4010. Theinteractions may be used to refine the determined user preferences 4012.The new interactions, such as for example, a user selecting the newdesign, may indicate that the parameters of the new design aredesirable.

FIG. 41 shows aspects of an apparatus for evaluating design with userinteraction using a card interface. The apparatus may include a cardinterface component 4102. The card interface component 4102 may be partof the interfaces facility 112 of the platform 104. The card interfacecomponent 4102 may display and monitor an interactive card interfacethat enables interactive evaluation of designs. The card interface mayinclude a card presentation component 4104 that may generate a carddisplay for one or more simulated designs 4114. The card presentationcomponent 4104 may identify which values or parameters should bedisplayed for a design on a card. The card interface component 4102 mayinclude an graphic enhancement component 4108 which may be configured tochange the display of one or more aspects of a card to highlight aproperty, value, rating, ranking, and the like of the design displayedby the card. For example, the highlighting may be relative to otherdesigns shown on the cards. Designs that have a parameter higher thanthe other designs displayed may have the parameter highlighted on thecard of the design. The card interface component 4102 may include aninteraction analysis component 4106 configured to monitor user input4116 with the interface. Interaction analysis component 4106 may beconfigured to infer one or more preferences 4118 for one or moreparameters of the designs based on the interactions. The interactionanalysis component 4106 be configured to receive historical interactiondata 4112 to identify patterns or trends in previous interactions andpreferences to identify how interactions with the present interfacerelate to preferences. The preferences may be used by the cardsuggestion component 4110 to identify new designs to be displayed in acard. The new design may be consistent with the determined preferences4118. In some embodiments the new design may be selected to provide newinformation about preferences and may not be consistent with thepreferences 4118.

FIG. 42 shows aspects of an apparatus for evaluating design with userinteraction using a card interface. In embodiments, the interfacescircuit 4202 may include an interaction analysis circuit 4204 and asimulation results processing circuit 4206. The interaction analysiscircuit 4204 may process interaction data 4214 from a user. Theinteraction data 4214 may relate to user interactions with data andcomponents of an interactive interface. The interface may, during theinteraction, display design data in a card interface. The design datamay be received from a recommendation circuit 4212. The interfacecircuit 4202 may further include a suggestion circuit 4208 that may beconfigured to analyze processed user interaction data from theinteraction analysis circuit 4204 and data provided in the interfacefrom the simulation results processing circuit 4206 and determine userpreferences 4216 for designs. The interface circuit 4202 may include agraphic enhancement circuit for highlighting or emphasizing one or moreparameters or values displayed on the card. The emphasizing may be dueto the value being substantially (such as 10% or more) higher or lowerthan the other designs. The card suggestion circuit 4208 may identifywhich designs to present using the card interface. The card suggestioncircuit 4208 may determine designs based on the determined preferences4216. The card suggestion circuit 4208 may determine designs to displayon the card interface in order to determine new preferences.

In embodiments, the interactive graphical interfaces may include atornado diagram interface that may be used to evaluate simulateddesigns. In embodiments, designs may be evaluated for their sensitivityto changes in scenarios and/or other parameters. A tornado chart is atype of sensitivity analysis that provides a graphical representation ofthe degree to which the result is sensitive to the specified independentvariables. Tornado visualization may be configured for viewingtrade-offs and obtain answers to what-if questions in real-time. Inembodiments, an interactive tornado diagram for sensitivity analysis ofpromising designs may use categorization of design parameters,including: decision variable vector, scenario vector, performancecriteria, and the like. The tornado diagrams may be configured to helpin visually analyzing the effect of change in design and scenariovectors on the performance, and to identify the desirable design spacecombination to have optimum performance criteria values.

FIG. 43 shows example aspects of a tornado dashboard for evaluatingsensitivity of design. In embodiments, the dashboard may include one ormore tornado diagrams (three tornado diagrams are shown 4302, 4304,4306). In embodiments, tornado plots may be used to analyze thesensitivity of designs and decision variables with respect toperformance criteria. A set of tornado plots that may be used to assessand compare the sensitivity of various designs and decision variables.In embodiments, an interface may be presented to a user allowingcomparison of sensitivity designs and variables with respect to two ormore performance criteria. In some embodiments, input elements 4308,such as slides, text boxes, checkboxes, and the like, may be provided tochange values of variables and options that are shown in the plots.

In embodiments, the interactive graphical interfaces may include aheatmap interface that may be used to evaluate simulated designs. Aheatmap interface may show a magnitude of a performance parameters fordifferent designs using colors and shading. The heatmap may be arrangedin a grid or a matrix. The heatmap may be arranged such that onedimension may list designs while the other dimension may listparameters. In embodiments, the heatmaps may be clustered heatmaps wherethe parameters may be clustered according to different criteria.

A heatmap provides an interface to quickly visually compare, evaluate,and select designs. In embodiments a heatmap may provide for tens,hundreds, or even thousands of different designs with respect to tens,hundreds, or even thousands of different parameters or scenarios. Inembodiments, a heatmap may be configured or configurable to showdifferent relations and allow a user to compare and evaluate differentdesigns against different parameters and/or scenarios. In embodiments, aheatmap may be configured or configurable to show different parametersfor the designs. The heatmap elements may be filtered according to oneor more filters. In embodiments, the elements may be reordered based onone or more criteria. Users may zoom or select a subsection of aheatmap.

In embodiments, users may evaluate designs by changing views of aheatmap or showing more than one heatmaps with different configurations.In embodiments, users may mark one or more designs in one heatmap or oneconfiguration of a heatmap. The marking of a design in one heatmap orone configuration of a heatmap may be propagated to other heatmaps orconfigurations of heatmaps with the same design. The selected design maybe highlighted or emphasized (such as a darker border, a different colorof border, a flickering of colors, and the like) as a heatmap isreconfigured to show the selected design. In embodiments, a two or moredesigns may be selected and tracked between different heatmaps orheatmap configurations.

In embodiments, heatmaps may provide an option to display or emphasizeoptimal designs, Pareto designs, CH-designs, and/or other recommendeddesigns. The designs may be highlighted and/or emphasized to show theirlocation in the heatmap and may show animations or other indicators toshow changes in locations of the designs in the heatmap when a heatmapis reconfigured. Designs and/or cells that are highlighted or emphasizedmay be deselected, dismissed, flagged, marked, and the like by the user.Designs that are dismissed may be deemphasized and no longer tracked inthe heatmap. User interactions with the heatmap may be tracked toidentify user preferences for designs. In some embodiments, a user mayidentify regions of the heatmap (such as by drawing or indicating anarea such as a circle, square, or other shape) to indicate an area ofinterest or to indicate an area that does not include relevant designs.The areas that are indicated to not have designs may be filtered fromthe heatmap. Areas that are indicated as areas of interest may triggeradditional simulations. For example, marking an area as an area ofinterest may trigger simulated annealing analysis to identify otherdesigns that may be similar to those in the area of interest. Inembodiments, selections of elements in the heatmap may trigger automaticupdates to definitions of the criteria space, design space, scenariospace, and/or performance space and may trigger additional simulationsand/or additional analysis (such as recomputing P-designs, CH-designs,and the like).

In embodiments, heatmaps may provide features to emphasize some designs.In heatmaps with a large number of designs, the color and/or shadingthat represents a value of a design with respect to a parameter may havea small area on the interface. The small area of the color may make itdifficult to distinguish the value represented by the color from nearbyor neighboring colors. In some embodiments, the heatmap interface mayidentify cells that may be of interest to a user (such as representativeof a high or desirable value) but may not be clearly visible due tosmall size or the colors of neighboring cells. In embodiments the cellsmay be emphasized with changing colors, flickering, distinguishedborders, or other effects to distinguish the cell from surroundingcells.

FIG. 44 shows aspects of a heatmap. A heatmap 4402 may be displayed as agrid of cells. The rows of the grid may correspond to different designsand the columns may be representative of different scenarios. Each cellmay be colored or shaded to be representative of a value (such as ascore) of the design for a scenario. The configuration of heatmap may bechanged by changing aspects of the score, aspects of what designs andscenarios are represented, the ordering of the designs and scenarios,and the like. The score shown for each cell may be configured in a scoredefinition part of the interface 4404. The score definition part 4404may provide for a configuration of the weights used for computing thescore and/or the parameters used to calculate the score. The interfacemay include components to filter scenarios 4406 and components to filterdesigns 4408. The interface may include options 4410 to configure theheatmap for displaying different aspects such as what score is shown,which design and scenarios are shown. The component 4410 may includepreset options for filtering and configuring the heatmap. Inembodiments, users may mark one or more cells in the heatmap. The markedheatmaps may be visually emphasized and may be tracked as the heatmap isreconfigured.

In embodiments, the interactive graphical interfaces may include atradeoff advisor. A tradeoff advisor may include a graphical interfacemay provide one or more displays for selecting data for comparison andgraphing. The tradeoff advisor may provide a display of heatmaps,scatter plots, tornado plots, and other graphs for visualizingrelationships between aspects of the designs. In embodiments,relationships between strategic goals, variables, parameters, values,and the like may be automatically determined for a set of simulatedtrial options. In some cases, users may choose to select a parameterand/or strategic goal, and the platform may determine two (2) or three(3) or more variables and/or parameters that have the biggest impact onthe selected parameter and/or strategic goals. The platform may generateone or more graphs showing the relationship between the parameters. Forexample, a user may select one output of interest (duration, cost, eNPV,probability of success, etc.). The platform may use sensitivity analysisto automatically put the two (2) or three (3) biggest drivers for thatoutput on the two (2) or three (3) axes for a display chart. Inembodiments, a user may select to show parameters or variables that havethe biggest impact, lower impact, average impact, variable impact, andthe like. The relationships may be used to set filters, rank importanceof variables or parameters, and the like.

In embodiments, interactive interfaces (such as the card interface,heatmap interface, tornado interface and the like described herein) maybe used to evaluate and configure parameters and/or criteria beforesimulation. Parameters and values of the parameters for design space,scenario space, criteria space, and/or performance space may bedisplayed using one or more interactive interfaces. Interactions may bereceived to configure one or more of the spaces. For example, heatmapsmay be used to visualize scenario parameter values that have beendetermined for simulation. Regions in the heatmap may be identifiedusing the interface to exclude some scenarios. In some cases regions ininterest in the heatmaps may be identified to add additional parametersor ranges of values to the spaces.

In embodiments, interactive interfaces may include reporting and alertfeatures. In embodiments, outputs of interfaces may be provided inreport format for users. In embodiments, reports may be automaticallygenerated and stored for documentation of design and analysismethodologies. In embodiments reporting may be based on the types and/ornumber of interactions observed. In some cases reporting may provide asummary of how interactions were interpreted and used to determinepreferences and/or recommended designs.

Referring now to FIG. 45, an embodiment of the architecture/analysisplatform 104 (also shown in FIG. 1) is depicted. The platform 104 mayinclude a primary algorithm 4510 that controls and/or monitors theworkflow of the platform 104, e.g., queuing (ordering), cueing(invoking), starting and/or stopping execution of one or more algorithmsand/or engines; procurement of inputs; delivery of outputs, performance,progress updates; and/or the like. While FIG. 45 depicts the primaryalgorithm 4510 as being within the analysis facility 108, it is to beunderstood that, in embodiments, the primary algorithm 4510 may formpart of, extend, and/or have access to one or more other components ofthe platform 104, e.g., the configuration facility 106, simulationfacility 110, interface facility 112, data facility 138, computingresources 150, and/or the like. In certain aspects, the primaryalgorithm 4510 may interface with other algorithms/engines/modules andtechniques such as simulated annealing 4516 modules, Pareto modules4512, convex hull modules 4514, Monte Carlo modules 4516, visualizationtools/engines, recommendation algorithms/engines, and/or the like 4518.As described in greater detail herein, embodiments of the primaryalgorithm 4510 may structure and/or control the flow of data through theplatform 104. Data flow through the platform 104 may be facilitated bydata records that are stored and retrieved from one or more databases indata facility 138. In other words, embodiments of the primary algorithm4510 may provide for a configuration of the platform 104, also referredto herein as a platform configuration. A data record may include one ormore variable types, e.g., string, integer, long, scalar, etc., in rowsand columns. Data records may conform to a relational schema so thatseveral data records collectively represent a higher-level data object.As used herein with respect to the platform 104, the terms“configuration” and “platform configuration” include the arrangement,sequencing, and/or manipulation of one or more components of theplatform 104, e.g., sequencing of models and/or engines, sequencingand/or configuration of algorithms, control of data flow and/or thelike. In certain aspects, the platform configuration may be based ondata analysis, user inputs, and/or the like.

For example, FIG. 46 depicts a method/workflow execution controlstructure of an embodiment of the primary algorithm 4510. The primaryalgorithm 4510 may include obtaining a trial design specification for aclinical trial design 4610 and obtaining one or more componentspecifications for one or more components of the platform 4612. Acomponent specification may include one or more levels of specification.For example, in one level, the component specification may includespecific configurations of components such as which algorithms will beused, order of execution, the types and versions of simulation engines,and/or the like. In another level, the component specification mayinclude high-level, and/or generalized, descriptions/objectives that mayspecify how long a design study should take and/or a cost of performingthe design study. In the case of a high-level description, the componentspecification may be used to automatically, or semi-automatically,identify details of a configuration to achieve the high-leveldescription. For example, based on a high-level specification of a cost,a configuration may limit the number of designs simulated, the number ofsimulation runs for each design, the fidelity of the simulations, numberof analysis algorithms executed, and the like. The one or morecomponents may include an engine, one or more algorithms, models,databases, computing resources, storage resources, and/or any othercomponent of the platform 104 described herein. The algorithms mayinclude Pareto analysis algorithms, convex hull algorithms, simulatedannealing algorithms, Monte Carlo algorithms, recommendation algorithms,and/or the like. The trial design specification may include a simulationtime, a runtime, a type of analysis, a performance criteria, and/or thelike. In embodiments, the trial design specification may include apreference for a number of recommended designs, a type of visual output,a type of interactive interface, and/or the like. The one or morecomponent specifications may include a cost, a runtime, a requiredresource, a version, and/or the like.

The primary algorithm 4510 may further include determining, based atleast in part on the trial design specification and the one or morecomponent specifications, a configuration for the analysis platform4614. The configuration may be a data file and/or other type of datastructure that defines various aspects of the platform 104, e.g.,sequencing and/or type of algorithms, location of inputs, and/or anyother type of configurable property of the platform 104 describedherein. For example, in embodiments, the configuration may call forfiltering simulated trial designs by first applying a Pareto algorithmfollowed by applying a convex hull algorithm. The configuration may thencall for the results of the convex hull algorithm to be assessed viasimulated annealing to detect if the current results are a local maximaor minima with respect to the desired performance criteria. Inembodiments, the primary algorithm 4510 may include executing ananalysis of the clinical trial design 4616 via the analysis platform104, as described herein, using the configuration. As further shown inFIG. 45, in certain aspects, the primary algorithm 4510 may includetransmitting the configuration 4618. Determination of the configuration4614 may include determining an order of execution for one or moreanalysis algorithms 4620. In certain aspects, the configuration may bebased on historical data and/or derived/predicted via machine learning.For example, artificial intelligence may be used to recognize and/orrecommend particular configurations as being suitable for a particulartype of clinical trial.

In one example, the primary algorithm may determine a configuration ofthe analysis platform based in part on the number of designs that areexpected to be simulated for a study. The primary algorithm, may, beforesimulations are executed, analyze the configuration for simulation todetermine or estimate the number of designs for which performanceparameters will be determined. The number of designs may be estimatedbased on the number of design/scenario parameters (the number ofparameters may correlate to the number of designs that will besimulated), based on the types of simulations scheduled (exhaustivesimulations, partial simulations, or based on simulated annealing). Theprimary algorithm may determine which analysis algorithms should beexecuted to provide the user with sufficient (not too many) recommendeddesigns. In one instance, if exhaustive simulations are scheduled, theprimary algorithm may configure the analysis platform for the convexhull algorithms to reduce the number of design suggestion. In anotherinstance, if partial simulations are scheduled, the primary algorithmmay configure the analysis platform for Pareto algorithms in order toprovide for a sufficient number of recommended designs.

Turning to FIG. 47, an apparatus 4700 for implementing the primaryalgorithm 4510 is shown. The apparatus 4700 may be one or moreprocessors, as described herein, that form part one or more servers,e.g., computing resources 150 (FIG. 1). The apparatus 4700 may include aspecification receiving circuit 4710 structured to interpret trialdesign specification data 4712 and one or more component specificationdata 4714. The apparatus 4700 may further include a configurationdetermination circuit 4716 structured to generate platform configurationdata 4718 based at least in part on the trial design specification data4712 and the one or more component specification data 4714. Theapparatus 4700 may further include an evaluation circuit 4720 structuredto analyze the clinical trial design via the analysis platform 104, asdescribed herein. In embodiments, the evaluation circuit 4720 maygenerate evaluation data 4722 which may be transmitted by the apparatus4700 via an evaluation data provisioning circuit 4724. The apparatus4700 may further include a graphical user interface circuit 4726structured to generate graphical user interface data 4728 configured toprovide a graphical user interface. The apparatus 4700 may furtherinclude a user input processing circuit 4730 structured to interpretuser input data 4732.

In certain aspects, the apparatus 4700 may provide for results and/orintermediate data of the analysis of one or more clinical trials to betransmitted and/or accessed by a user interface (which may be providedby the graphical user interface circuit 4726) for review, analysis,visualization, and manipulation. The user interface may receive userinput data 4732 for design selections, parameters, and/or the like. Theapparatus 4700 may provide an interface (which may be provided by thegraphical user interface circuit 4726) for interacting with externaltools and/or engines for simulation and/or analysis. In someembodiments, the apparatus 4700 may record and/or track the processesand/or inputs for a session and/or design study. The apparatus 4700 maytrack the sequence of steps and/or algorithms/engines used for theanalysis of data and may further record and/or track user selectionsand/or actions. The apparatus 4700 may analyze recorded sequences ofprocesses, user actions, and/or selections to learn from past actionsand results to determine the most appropriate (i.e., the fastest, themost accurate, etc.) sequence of algorithms for providing userrecommendations. In embodiments, the apparatus may learn via artificialintelligence, e.g., a neural network, as disclosed herein. Inembodiments, the primary algorithm 4510 may facilitate communicationbetween any two or more of the algorithms described herein. For example,the platform may track and record which platform configurations resultedin a faster design consensus. The platform may track which platformconfiguration and which combination of analysis configuration resultedin less time between when designs were presented/recommended to a userand when a final design was selected. Faster time for selection may beindicative that the platform provided the user with recommended designsthat were acceptable since the user spent less time considering otheroptions or performing additional simulations and/or analysis. The systemconfiguration that was related to faster consensus may be tagged as morefavorable. Based on the tags, the platform may analyze a configurationof simulation configurations and analysis configurations.

In embodiments, analysis of design options may include a Paretoanalysis. A Pareto optimal analysis may be used for algorithmicgeneration of design recommendations. Pareto analysis may be used todetermine one or more Pareto optimal designs (also referred herein as“Pareto designs” or “P-designs”). Initial selections of a set ofcandidates for best or optimal designs may be selected using a Paretofrontier that is generated by the Pareto designs.

Pareto analysis may identify designs that are Pareto optimal for the oneor more performance parameters. Pareto optimal designs may be designswhere no individual performance parameter can be better off withoutmaking at least one other individual performance parameter worse off.The set of Pareto optimal designs may form a Pareto frontier. Paretooptimality may be used as an optimality criteria.

Referring again to FIG. 1, the filtering component 120 (FIG. 1) mayinclude Pareto analysis. The filtering component 120 may includecircuits, components, and algorithms for enabling Pareto analysis. Thefiltering component 120 may receive simulation data from the simulationfacility 110 and analyze the simulated data to identify one or moredesigns using Pareto analysis techniques. The identified designs may berecommended to a user.

FIG. 48 shows a graphical representation of aspects of Pareto analysis.FIG. 48 further shows a graph with points wherein each point correspondsto a trial design. The graph shows the performance of each trial designwith respect to two trial design parameters (e.g., maximum probabilityof technical success and maximum time to patent expiry) that may havebeen determined by simulation. As depicted in 48, it may be the casethat the higher the number of the parameter, the more desirable theparameter is. Points in the top right quadrant (represented by box 4802)of the graphs may relate to designs having more desirable performanceparameter values. In the illustrated example, Pareto analysis is used todetermine Pareto optimum designs in the top right quadrant 4802. Asfurther shown, the Pareto designs are connected by a line that is thePareto frontier 4804. As will be appreciated, the Pareto designsrepresent designs where no individual performance parameter can bebetter off without making at least one other individual performanceparameter worse off.

The Pareto frontier may be computed for a subset of all the trialdesigns. In some cases, the Pareto frontier may be computed for trialdesigns that have at least a threshold value for one or more performanceparameters. In the example of FIG. 48, the Pareto frontier is determinedonly for the trial designs that are in the top right section/quadrant4802 of the graph and relate to a threshold of at least 90% in both thetwo performance parameters considered. The thresholds may be based onthe goals considered, may be set by a user, algorithmically determined,and/or the like. FIG. 48 also shows trial designs that do not meet the90% threshold for the two performance parameters are omitted fromconsideration, and a Pareto frontier is determined only for the designsthat meet the thresholds.

In embodiments, the Pareto designs (and, hence, the Pareto frontier) maybe determined using various methods such as, but not limited to, ascalarization algorithm, a skyline query, weighted sums, and/or thelike.

In embodiments, Pareto designs may be identified as globally optimumdesigns and the Pareto designs may be recommended to a user. In someembodiments, Pareto designs may be identified as initial globallyoptimum designs and they may be used to refine the optimality criteriato identify other globally optimum designs for the new criteria. In someembodiments, interactive methods can be used in which a person, or analternate algorithm, acts as a decision-maker and interacts with themethod to indicate a preference for designs (such as preference amonginitial Pareto designs). In such embodiments, the method may use thepreference information to determine other trial designs (and modifyoptimality criteria) based on the preference of designs. In embodiments,the Pareto designs can be used to elicit the user's preferences byinteractively querying the user to make comparisons between designs.

Trial designs that are on or near the Pareto frontier may be selected asinitial choices for evaluation by a user. One or more of the designs maybe presented to a user to evaluate and provide feedback. Feedback mayinclude data related to acceptance of a trial design, rejection of atrial design, identification of one or more parameters or features of atrial design, and/or the like. In embodiments, the one or more trialdesigns from the Pareto frontier may be presented to a user using cards,tornado diagrams, heatmaps, and/or other similar interfaces as describedherein.

In some cases, the platform may receive feedback, e.g., user feedback,regarding recommended Pareto designs. Based on the feedback, optimalitycriteria may be changed. Changes in optimality criteria may includeeliminating designs from consideration. When designs are eliminated fromconsiderations, a Pareto analysis may be performed on the remainingdesigns which may result in new Pareto designs. In some cases, a changein optimality criteria may include a new and/or modified criteria thatprovides for a “second best” Pareto frontier to be computed. A “secondbest” Pareto frontier may include designs that are Pareto optimal whenthe initial Pareto designs are eliminated. The second best Paretodesigns may represent a second “level” of a Pareto frontier. In somecases, multiple “levels” of Pareto frontiers may be computed. In somecases, recommendations to users may include designs from the second bestPareto frontier and/or other levels, e.g., “third best”, “fourth best”,etc. Recommendations to designs in other levels may identify otherdesign types that may be preferable. Recommendations to designs in otherlevels may identify design that are more robust than designs in thefirst level and may be more desirable due to their robustness even ifthey have worse performance with respect to other performanceparameters. In embodiments, interfaces such as tornado diagrams, cardinterfaces, heatmaps, and the like (including as described herein) maybe used to evaluate initial recommendations determined using initialoptimality criteria. Received feedback regarding the designs may be usedto refine recommendations and optimality criteria used to determineglobally optimum designs.

In embodiments, the optimality criteria may be modified according to thenumber of Pareto designs that are identified. Pareto designs maysometimes cluster. Some Pareto designs may be very close to other Paretodesigns. Differences in the designs may be small and/or within theexpected simulation error of the designs. In some cases, the Paretodesigns which are close together may be filtered or grouped together. Insome cases, a first Pareto design may be used to temporarily representone or more other Pareto designs that are close to the first Paretodesign to reduce the number of Pareto designs that are considered.

Pareto analysis may be configured to separate Pareto designs that aretwins (designs that have equal or nearly equal performance parameters orobservables such as cost, power, and/or time, twins may be designs thatare within simulation error for example) and/or siblings (designs thatare similar with respect to performance parameters or observables). Insome cases, similarity for twin and/or sibling determination may bebased on thresholds, such as designs that are within an ε-box of eachother. In embodiments, one or more first designs may be consideredwithin an ε-box of a second design when the one or more first designsare within a ball of radius ε from the second design. Designs that aretwins or siblings may be flagged or marked for further analysis if theyare deemed to have desired performance as the twins or siblings mayrepresent different design options that can be used to achieve similarperformance criteria.

In embodiments, the Pareto analysis may further identify dominateddesigns. Dominated designs may be designs that are dominated by one ormore other Pareto designs. Dominating Pareto designs may be better forone or more of the dominated designs for one or more design criteria.From the dominated designs, Pareto analysis may identify designs thatare clustered by the dominating Pareto designs. The designs that areclustered may be identified using ε-criteria. The ε-criteria may be athreshold as to how far the dominated designs may be from the dominatingPareto designs to be included in the set of clustered designs. Theε-criteria may be a measure as to how similar designs should be to beclustered together. The threshold and similarity measures may bedirected to the performance parameters of each design, such as the cost,duration, etc., of each design. For example, for performance parameterp, a design may be within ε-criteria if a design is within p±ε.

Pareto designs may be filtered or grouped, and one or more other Paretodesigns that are within ε of another Pareto design may be represented byone Pareto design. In other words, a dominating Pareto design mayrepresent one or more dominated Pareto designs. In one example, the setof Pareto designs may be filtered to a smaller set of ε-filtereddesigns. The size of the set of ε-filtered designs may be adjusted,e.g., made larger or smaller, by selecting the value of ε. In somecases, ε may be selected to be about 0.001, and/or about 0.055, and/orabout 0.15. The ε-filtered designs may remove designs that are withinε-distance of another design. In some cases, the ε may be selected suchthat the number of ε-filtered designs is less than a predeterminedand/or desired number such as one hundred (100), ten (10), or less thanten (<10). The ε-filtering may be performed with respect to performanceparameters, design parameters, scenario parameters, and the like. Inembodiments, ε-filtering may reduce the number of designs recommended toa user, and may increase the range or variety of designs that arerecommended to a user by eliminating designs that are close to oneanother. In embodiments, ε-filtering may reduce clutter on a userinterface and/or the number of computations performed.

In some embodiments, ε-filtered designs may be recommended and/orevaluated by a user to determine if the set includes designs with designcriteria that are desirable. When a design from the ε-filtered designsis selected, the Pareto designs that were ε-filtered may be provided tothe user for further evaluation. The ε-filtered designs may have similardesign criteria to the selected design but may relate to different typesof designs. The user may evaluate different design types and designoptions that are within ε of the desired/selected design criteria.

Pareto analysis often requires new configurations and considerationswhen applied to clinical trial design optimization. In one aspect,clinical trial simulation (CTS) data is usually different from data inother applications. For example, in many other applications, points incriterion space are continuous or form a lattice while, in the currentapplication, points correspond to discrete designs. In many otherapplications, there may be a very large number of points on the Paretofrontier and the focus may be to produce a handful of well spread outpoints on the Pareto frontier for a decision-maker to study closely todetermine and/or select the best solution. CTS data, on the other hand,is typically highly clustered in certain regions of criterion space withsubstantial parts of the space being empty due to practical limits andconstraints, e.g., continuous adaptation after each subject) and/or dueto there being a handful of design types for a particular trial (fixedSS, SSR, Group Sequential, tailored innovative designs and the like).

Pareto analysis for the clinical trial optimization applications may bedesigned to cluster dominated designs into Pareto clusters and providean input consisting of only Pareto designs to convex hull algorithms inpreparation for creating convex hull clusters with a simple geometricalstructure in the criterion space. Additional unique aspects, of someembodiments, include a focus on interactive clinical trial simulationslinked with visualizations of performance criteria space, design factorsspace, and/or scenarios. Links between Pareto designs and close butdominated designs may be generated as a byproduct of finding the Paretoset. Dominated designs may be preferred for qualitative reasons (e.g.,complexity in trial execution, sensitivity to extreme downsidescenarios). Pareto points that are close to other points may beautomatically suppressed in a corresponding visualization (e.g., becausethey are unimportant due to being in the area within the margin of modelerror). Dominated designs can be unmasked when needed (e.g., when thedesigns are qualitatively different). Hierarchical level two (2), levelthree (3), etc. Pareto sets may be generated by rerunning the analysis.In embodiments, the analysis may accommodate constraints on designparameters, and dynamically updating the Pareto set by removing designs,adding new designs and scenarios, and/or changing prior probabilities ofscenarios. In embodiments, the analysis may be applied in stages tofirst find Pareto points in clusters of similar design sets (e.g.,changes of one parameter change, qualitatively different). Inembodiments, the analysis may be useful for gaining insight into designimprovements. In embodiments, clustering points in design spacedistances are natural and may be efficient for users to gain insights.In embodiments, the analysis may be integrated with a simulatedannealing engine that uses weights and/or target criteria points inunexplored regions.

Pareto analysis may provide for organization and/or analysis of datathat is comprehensible and/or provides for a focus to designs that areoptimal or near-optimal. The Pareto analysis may determine thehierarchies of design sets for consideration. In embodiments, one set inthe hierarchy may be ε-filtered Pareto designs, another may be allPareto designs, and/or another hierarchy may be designs that are withinε of the Pareto designs. The design space may be explored using thehierarchies to find designs that have the desired criteria and furtherto find designs that achieve the desired criteria with desired oracceptable design types.

In embodiments, Pareto analysis may be a two-pass analysis. In the firstpass, the simulation records (e.g., summary records) may be sorted bymaximum and/or minimum values of the performance parameters. Varioussorting algorithms (including those described herein) may be used. Inthe second pass, after the records are sorted, each record may becompared with all the records that follow in the ordered set to identifywhich records are ε-dominated by the record. After the second pass, thealgorithm may provide a set of Pareto designs which are not ε-dominatedby any other design and/or Pareto clusters of dominated designs linkedto one-or-more Pareto designs. If ε=0 for all performance criteria, thenthe full set of Pareto designs may be produced. If ε>0 for someperformance criteria, then the set of ε-filtered Pareto designs may beproduced, which is a subset of the full set of Pareto designs since someof the Pareto designs from the full set may be ε-dominated by otherPareto designs.

FIG. 49 shows aspects of the Pareto analysis using numerical examples.As shown in FIG. 49, each row in the table represents a design with theperformance parameter values listed in the columns. In the depictedexample, all of the designs are Pareto designs identified by a unique“PSet” number. In the first pass of the algorithm/engine, the P-designsare sorted, and the designs with the highest power, the lowest cost, andthe lowest duration are determined (PSet 1, 2, 3, respectively). In thesecond pass, the top three (3) P-designs (PSet 1, 2, 3) are compared toall remaining designs according to the selected ε for each performanceparameters. Based on the values of ε, some of the remaining designs maybe classified dominated by one of the first three (3) P-designs. Asfurther shown in the example of FIG. 49, PSet 7, 13, and 19 aredetermined to be dominated by PSet 1 for the ε values chosen (denoted by“−1” in the EPSet column). The algorithm may proceed to the next Paretodesign after all the ε designs for the first Pareto design weredetermined. The next Pareto design considered may be a design that hasnot been identified as ε-dominated design. In this example, PSet 2 isnext determined to dominate PSet 8, 11, 17, and 20 designs (denoted by“−2” in the EPSet column) The analysis may proceed to iterativelyprocess all the Pareto designs that are not dominated by other designsto determine the set of ε-filtered Pareto designs. In this example, theε-filtered Pareto designs (designs denoted by positive numbers by theEPSet column) are a subset of the Pareto designs and includes nine (9)designs. The algorithm may be iterated multiple times, and some designsmay be dominated by more than one Pareto design.

In embodiments, the ε-filtered Pareto designs may be used for initialrecommendations and/or consideration for users. The designs dominated byeach ε-filtered design may be further recommended or provided forconsideration when a design from the ε-filtered set if selected forfurther analysis by a user.

In embodiments, the Pareto analysis may be configured to quickly updatethe identified Pareto designs when new designs are introduced as inputsto the algorithm. The set of identified Pareto designs may be augmentedincrementally by the algorithm as new designs are identified/simulatedand added to the design space.

FIG. 50 shows aspects of an apparatus for determining globally optimumdesigns using Pareto analysis. In embodiments, the Pareto analysiscomponent 5002 may be part of the analysis facility 108 of the platform104. The Pareto analysis component 5002 may receive data from simulateddesigns 5012 and determine one or more sets of optimal designs 5022which may include Pareto designs 5024, dominated designs 5026 (designsthat are dominated by Pareto designs), ε designs 5028 (designs that arewithin a distance ε of Pareto designs). The Pareto analysis component5002 may include one or more circuits for determining recommendeddesigns. The circuits in the Pareto analysis 5002 may be selectivelyenabled according to user input 5020, ε values 5014, and other inputs.In embodiments, the Pareto analysis component 5002 may include circuitsfor determining Pareto optimality using Pareto algorithms 5030. Inembodiments, the Pareto analysis component 5002 may include circuits fordetermining optimality using ε filtering 5004. Epsilon filtering circuit5004 may determine designs that are within epsilon of Pareto designs.The Pareto analysis component 5002 may include Pareto level analysiscircuit 5032. Pareto level analysis circuit 5032 may determine one ordifferent levels of Pareto designs and Pareto frontiers. In embodiments,the Pareto analysis circuit 5002 may include circuits for dominateddesigns analysis 5006. Dominated designs analysis circuit 5006 mayidentify designs that are dominated by one or more Pareto designs andfilter the designs and/or recommend the designs according to user input5020 and/or epsilon values 5014. In embodiments, the Pareto analysiscircuit 5002 may include circuits for twins/siblings analysis 5008.Twins/siblings analysis circuit 5008 may identify designs that are twinsand/or siblings to one or more Pareto designs and filter the designsand/or recommend the designs according to user input 5020. Inembodiments, the Pareto analysis circuit 5002 may include circuits forclustered design analysis 5010. Clustered design analysis circuit 5010may identify designs that are clustered with one or more Pareto designsand filter the designs and/or recommend the designs according to userinput 5020.

FIG. 51 shows aspects of an apparatus for determining global optimalityof designs. In embodiments, the apparatus may include an optimalityanalysis circuit 5116 which may be part of the analysis facility 108 ofthe platform 104. In embodiments, the apparatus may include a dataprocessing circuit 5108 structured to interpret/obtain design data 5102of a clinical trial design. In some embodiments the design data 5102 maybe outputs of simulation data of trial designs. The output processingcircuit 5108 may transform the design data 5102 into a format suitablefor use by the various circuits in the apparatus. For example, thedesign data 5102 may be received by the data processing circuit 5108 anddetermine and identify performance parameters in the data. In someembodiments, some performance parameters may be grouped, filtered,converted, normalized, and the like.

The apparatus of FIG. 51 may further include an optimality determiningcircuit 5110 structured to receive processed design data from the dataprocessing circuit 5108. The optimality determining circuit 5110 mayidentify globally optimum designs 5114 based on Pareto analysis. In someembodiments, the globally optimum designs 5114 may be provided as anoutput of the apparatus. In some embodiments, globally optimum designs5114 may be further processed by the design analysis circuit 5112. Thedesign analysis circuit 5112 may analyze the globally optimum designs5114 and determine characteristics of the designs, receive feedback data5104 about the designs. The design analysis circuit may, based on thedetermined characteristics determine modifications for optimalitycriteria used in the optimality determining circuit 5110. The optimalitydetermining circuit 5110 may modify optimality criteria of Paretoanalysis. The modifications may include epsilon filtering of Paretodesigns, determining multiple levels of Pareto designs, clustering ofPareto designs, determining dominated Pareto designs, and/or the like.Using modified optimality criteria, the optimality determining circuit5108 may determine a new set of globally optimum designs 5114.

As shown in FIG. 52, a method for determining optimum designs usingPareto analysis may include obtaining trial design simulations 5202. Themethod may further include determining one or more score for each trialdesign based on the performance parameters 5204. The method may includeevaluating Pareto optimality for each design to determine Paretofrontier 5206. Designs not on the Pareto frontier may be filtered 5208.Designs on the Pareto frontier may be presented for further analysis5210.

As shown in FIG. 53, a method for determining optimum designs usingPareto analysis may include obtaining trial design simulations 5302. Themethod may further include evaluating optimality for each design usingPareto analysis 5304. The method may include identifying optimal designsbased on the Pareto analysis 5306. The optimum designs may be evaluated5308. Evaluation may include feedback from user, statistical analysis,and the like. Based on the evaluation, the Pareto analysis may bemodified 5310. Modifications may include determining epsilon-distancedesigns, clustering, determining second level Pareto designs, filteringsibling and twin designs, and the like.

In embodiments Pareto analysis includes consideration of performance,design, scenario, and criteria spaces. Pareto optimality is determinedwith respect to performance parameters of the performance space. Theperformance parameters may be evaluated using simulation for differentdesigns defined by the design space. Each design in the design space isevaluated for different scenarios of the scenario space. Theperformance, design, and scenario spaces are defined according to thecriteria space definitions.

In embodiments, analysis of design options may include convex hull (CH)analysis. A convex hull analysis may be used for algorithmic generationof design recommendations. Convex hull analysis may be used to determineone or more designs that are on a convex hull (also referred herein asconvex hull designs or CH-designs). Initial selections of a set ofcandidates for best or optimal designs may be selected using a convexhull that is generated with convex hull analysis. Convex hull analysismay determine the smallest convex polygon shape that contains thedesigns.

Referring again to FIG. 1, the filtering component 120 may includeconvex hull analysis. The filtering component 120 may include circuits,components, and algorithms for enabling convex hull analysis. Thefiltering component 120 may receive simulation data from the simulationfacility 110 and analyze the simulated data to identify one or moredesigns using convex hull analysis techniques. The identified designsmay be recommended to a user.

FIG. 54 shows a graphical representation of aspects of convex hullanalysis. FIG. 54 shows a graph with points wherein each pointcorresponds to a trial design. The graph shows the performance of eachtrial design with respect to two trial design parameters (power andminimum study cost) that may have been determined by simulation. Forthese two performance parameters, the higher the number the moredesirable. Points in the top right quadrant of the graphs relate todesigns with the more desirable performance parameter values. In theexample, convex hull analysis is used to determine CH-designs. Theconvex hull is a line 5404 and CH-design are vertices of the line 5404.The convex hull contains or envelopes the other designs.

In embodiments, convex-hull designs are a subset of Pareto designs. Theyare often a fraction of the size of the set of Pareto designs. Animportant property of convex-hull designs is that they are that can beoptimal with respect to a performance criteria that is a linear weightedcriterion of the components of the multivariate performance parameters.

The convex hull of design may be computed for a subset of all the trialdesigns. In some cases, the convex hull may be computed for trialdesigns that have at least a threshold value for one or more performanceparameters.

In embodiments, various algorithms/engines may be used to compute convexhull points and may include brute force, gift wrapping, Graham scan,Jarvis, QuickHull, Qhull algorithms/engines, and/or the like.Computation of the convex hull of the designs may include additionaldata such as facet area and volume of the hull, facet normal vectors(weights for which the facet is optimal). Additional outputs may includetriangular facets (such as Delaunay) or polygon (polyhedral) facets. Inembodiments, outputs related to the facet area may be indicative of thenumber of designs from the CH-designs that are in the design space.Large facet areas may indicate that there are few design options in thedesign space area of the facet. Facet area information may be used as abasis for the exploration of the design space using simulated annealingalgorithms/engines and/or the like.

In embodiments, CH-designs may be identified as desirable or optimumdesigns and the CH-designs may be recommended to a user. In someembodiments, CH-designs may be identified as initial globally optimumdesigns and they may be used to refine the optimality criteria toidentify other globally optimum designs for the new criteria. In someembodiments, interactive methods can be used in which a person or analternate algorithm acts as a decision-maker and interacts with themethod to indicate a preference for designs (such as preference amonginitial CH-designs), and the method may use the preference informationto determine other trial designs (and modify optimality criteria) basedon the preference of designs. In embodiments, the CH-designs can be usedto elicit the user's preferences by interactively querying the user tomake comparisons between designs.

Trial designs that are on or near the convex hull may be selected asinitial choices for evaluation by a user. One or more of the designs maybe presented to a user to evaluate and provide feedback. Feedback mayinclude data related to acceptance of the trial design, rejection of thetrial design, identification of one or more parameters or features ofthe trial design, and the like. In an embodiment, the one or more trialdesigns from the convex hull may be presented to a user using the card,tornado, heatmaps, and similar interfaces described herein.

Convex hull analysis may output two or more sets of designs and mayinclude the convex hull designs and clustered convex hull designs (suchas designs that are non-reachable by weighting criteria). The sets ofdesigns determined by convex hull analysis may represent a hierarchy ofdesigns for recommendation and/or consideration by a user. The convexhull designs may be the first in the hierarchy and may be the firstdesigns to be recommended or provided for consideration. The clusteredconvex hull designs may be below the convex hull designs on thehierarchy of designs for recommendation and/or consideration. Theclustered convex hull designs may be provided for recommendation and/orconsideration after the set of convex hull designs or if no designs inthe set of convex hull designs are acceptable to a user. In some cases,the set of clustered convex hull designs may be larger than the set ofconvex hull designs.

Convex hull analysis may be configured to separate CH-designs that arehave equal or nearly equal performance parameters or observables such ascost, power, and/or duration. In embodiments, designs that are within anε-box of a design may be designs that are within a ball of radius ε froma design. Designs that are twins or siblings may be flagged or markedfor further analysis if they are deemed to have desired performance asthe twins or siblings may represent different design options that can beused to achieve similar performance criteria.

CH-designs may be grouped, and one or more other designs that are withinε of a CH-design design may be represented by one CH-design. The size ofthe set of ε-filtered designs may be larger or smaller by selecting thevalue for E. In some cases, ε may be selected to be 0.001, and/or 0.055,and/or 0.15.

Convex hull analysis for the clinical trial optimization applicationsmay be designed to cluster dominated designs into convex hull clusters(CH-clusters). In embodiments, the analysis may accommodate constraintson design parameters, and dynamically updating the CH-design by removingdesigns, adding new designs and scenarios, and/or changing priorprobabilities of scenarios.

Convex hull analysis may provide for organization and/or analysis ofdata that is comprehensible and/or provides for a focus to designs thatare optimal or near-optimal. The convex hull analysis may determine thehierarchies of design sets for consideration. In embodiments, one set inthe hierarchy may be CH-design, another may be clustered CH-designs. Insome embodiments, on CH-design hierarchy level may be the initialCH-designs. The next hierarchy level may be CH-designs that aredetermined when the initial CH-designs are not deleted and so on.Platform may drill down into the hierarchies when initial levels do notprovide acceptable designs.

In embodiments, inputs to convex hull analysis may include simulatedtrial designs. In some embodiments, inputs may be P-designs determinedby the Pareto algorithm/engine. In some embodiments, the inputs may be aset of trial design simulation records from a simulation database.Inputs may further include levels of minimum meaningful difference forperformance parameters (ε1, ε2, ε3, . . . ) specified by users ordefault values that are fixed or dynamic (data dependent). The valuesfor (ε1, ε2, ε3, . . . ) may depend on the stage of design exploration(e.g., larger values in early stages and smaller values in later stages,when more accurate information has been obtained), userperspective/choice, and/or the like. In some cases, inputs may includeupper and lower bounds for each performance parameter value.

FIG. 54 shows a graphical representation of aspects of convex hullanalysis. In embodiments, outputs of convex hull analysis may includethe set of convex hull designs (designs on vertices CH1, CH2, CH3, CH4,CH5). In the case where the inputs were Pareto designs, CH-design may bea subset of the Pareto designs. In the figure, Pareto designs correspondto vertices of line 5502 (the Pareto frontier). Some vertices of thePareto frontier correspond to the CH-designs (such as CH2 and CH3). Inembodiments, outputs may further include clusters of P-designs for eachconvex hull facet (CHF), e.g., (CHF12, CHF23, CHF45) of the convex hull.Clusters may be determined by a right triangle formed by the ends ofeach facet forming convex hull facet clusters (CHF clusters). Convexhull facet clusters may be non-overlapping (i.e., each P-design belongsto exactly one CHF cluster). Each CH-design may be at the intersectionof several facets so CHF clusters can be combined into a convex hullPareto cluster (CHP cluster) for each CH-design. CHP clusters may beoverlapping. As will be appreciated, this may provide a decompositionfor the global problem of optimization into smaller local problemsdefined for a CHF or CHP clusters.

In embodiments, outputs of convex hull analysis may include facet area,volume of the hull, facet normal vectors (weights for which the facet isoptimal). In embodiments, facet area, volumes of the hull, and normalvectors may be used by search algorithms such as simulated annealing todetermine search trajectories and parameters. In embodiments convex hullanalysis may be parallelized. Input designs may be partitioned into twoor more sets and a CH-designs may be determined for each set inparallel. The CH-designs of each set may be combined and overallCH-designs may be determined. In some embodiments, convex hull analysismay support batch updating in collaborative environments.

FIG. 56 shows aspects of an apparatus for determining designs usingconvex hull analysis. In embodiments, the convex hull analysis component5602 may be part of the analysis facility 108 of the platform 104. Theconvex hull analysis component 5602 may receive simulated design data5612 (which may include just P-designs from Pareto analysis) anddetermine one or more sets of optimal designs 5622 which may includeCH-(designs that are within a distance epsilon of CH-designs). Theconvex hull analysis component 5602 may include one or more circuits fordetermining recommended designs. The circuits in the convex hullanalysis component 5602 may be selectively enabled according to userinput 5620, epsilon values 5614, and other inputs. In embodiments, theconvex hull analysis component 5602 may include circuits for determiningconvex hull optimality using convex hull algorithms 5630. Inembodiments, the convex hull analysis component 5602 may includecircuits for determining optimality using epsilon filtering 5604.Epsilon filtering circuit 5604 may determine designs that are withinepsilon of CH-designs. In embodiments, the convex hull analysis circuit5602 may include circuits for dominated designs analysis 5606. Dominateddesigns analysis circuit 5606 may identify designs that are dominated byone or more CH-designs and filter the designs and/or recommend thedesigns according to user input 5620 and/or epsilon values 5614. Inembodiments, the convex hull analysis circuit 5602 may include circuitsfor twins/siblings analysis 5608. Twins/siblings analysis circuit 5608may identify designs that are twins and/or siblings to one or moreCH-designs and filter the designs and/or recommend the designs accordingto user input 5620. In embodiments, the convex hull analysis circuit5602 may include circuits for clustered design analysis 5610. Clustereddesign analysis circuit 5610 may identify designs that are clusteredwith one or more CH-designs and filter the designs and/or recommend thedesigns according to user input 5620.

FIG. 57 shows aspects of an apparatus for determining global optimalityof designs using convex hull analysis. In embodiments, the apparatus mayinclude an optimality analysis circuit 5716 which may be part of theanalysis facility 108 of the platform 104. In embodiments, the apparatusmay include a data processing circuit 5708 structured tointerpret/obtain design data 5702 of a clinical trial design. In someembodiments the design data 5702 may be outputs of simulation data oftrial designs. The output processing circuit 5708 may transform thedesign data 5702 into a format suitable for use by the various circuitsin the apparatus. For example, the design data 5102 may be received bythe data processing circuit 5708 and determine and identify performanceparameters in the data. In some embodiments, some performance parametersmay be grouped, filtered, converted, normalized, and the like. Theapparatus of FIG. 57 may further include an optimality determiningcircuit 5710 structured to receive processed design data from the dataprocessing circuit 5708. The optimality determining circuit 5710 mayidentify designs 5714 based on convex hull analysis. In someembodiments, the designs 5714 may be provided as an output of theapparatus. In some embodiments, designs 5714 may be further processed bythe design analysis circuit 5712. The design analysis circuit 5712 mayanalyze the designs 5714 and determine characteristics of the designs,receive feedback data 5704 about the designs. The design analysiscircuit may, based on the determined characteristics determinemodifications for optimality criteria used in the optimality determiningcircuit 5710. The optimality determining circuit 5710 may modifyoptimality criteria of convex hull analysis. The modifications mayinclude epsilon filtering designs, determining multiple levels ofCH-designs, clustering of designs, determining dominated CH-designs, andthe like. Using modified optimality criteria, the optimality determiningcircuit 5708 may determine a new set of designs 5714 which may berecommended to a user.

As shown in FIG. 58, a method for determining optimum designs usingconvex hull analysis may include obtaining trial design simulations5802. The method may further include determining one or more scores foreach trial design based on the performance parameters 5804. The methodmay include the convex hull for the designs 5806. Designs not on theconvex hull may be filtered 5808. Designs on the convex hull may bepresented for further analysis 5810.

As shown in FIG. 59, a method for determining optimum designs usingconvex hull analysis may include obtaining trial design simulations5902. The method may further include evaluating the designs to determinea convex hull 5904. The method may include identifying optimal designsbased on the convex hull 5906. The optimum designs may be evaluated5908. Evaluation may include feedback from user, statistical analysis,and the like. Based on the evaluation, aspects of the convex hullanalysis may be modified 5910. Modifications may include determiningepsilon-distance designs, clustering, determining second levelCH-designs, and the like. New optimal designs may be identified usingthe modifications to the convex hull analysis.

In embodiments convex hull analysis includes consideration ofperformance, design, scenario, and criteria spaces. Convex hull may bedetermined with respect to performance parameters of the performancespace. The performance parameters may be evaluated using simulation fordifferent designs defined by the design space. Each design in the designspace is evaluated for different scenarios of the scenario space. Theperformance, design, and scenario spaces are defined according to thecriteria space definitions.

In embodiments, the platform 104 may be configured to explore differentscenarios and perform “what if” analysis. The platform may be configuredto automatically or semi-automatically explore the robustness ofdifferent designs. Trial designs may be evaluated, for example,respective to a range of treatment effects. As depicted in FIG. 29, atrial design may be evaluated to determine the outcomes of the trialbased on whether the treatment effect is optimistic, base, orpessimistic, for example. In some embodiments, the analysis may includechanges to assumptions of the trial to determine how a change inassumptions may change the usefulness of the trial.

In embodiments, the platform may further provide additional sensitivityanalysis for designs. Models and designs may include assumptions aboutbehaviors, parameters, and the like of a study. Sensitivity analysis maybe used to determine behavior or trial designs in view of perturbationsand variations in the model assumptions and/or parameters. Sensitivityanalysis may be used to determine the robustness of designs. In someembodiments, the robustness of designs provides for a measure of whatvariations of assumptions a design can tolerate and still provide auseful result.

In embodiments, designs may be scored or evaluated based on multiplecriteria. In some cases, a series of different tests that evaluate asensitivity, robustness, and/or risk associated with a design may becomputed. In some cases, an overall composite score that takes intoaccount the multiple tests that can be computed.

FIG. 60 shows aspects of sensitivity analysis. In some embodiments, theseparation of trial design inputs and scenario inputs, as describedherein, may enable efficient sensitivity analysis. In embodiments, aframework for sensitivity analysis may compare how differentcombinations of design choices and scenarios affect performancecriteria. In one embodiment, a vector of scenarios (SV₁ . . . SV_(j) . .. SV57) may be arranged against each combination of designs (DV₁ . . .DV_(i) . . . DV₁₁₂₀). For each combination of a designs and scenario(SV_(i)DV_(i) combination) performance parameters may be determined,such as by simulating the design and scenario combination. Inembodiments, for each combination of a design and scenario, a weightedsum of performance parameters may be determined from simulation data.The arrangement of combinations and a weighted sum of performancecriteria may provide for a measure of how performance parameters foreach design change or are affected by variations in scenarios. Each rowof the table shown in FIG. 60, when populated with simulation data,would show how performance parameters (or a function of the performanceparameters) change over the scenarios. Each row of the table may showfor which scenarios and/or what values of scenarios results inacceptable levels of performance (such as performance values above athreshold value). In embodiments, a span of acceptable parameter valuesmay be related to the robustness or sensitivity of the design. Inembodiments, a span may be the number of scenarios for which a design ora design parameter generates acceptable parameter values. Inembodiments, a span may be a range of scenario parameter values a designor a design parameter that generates acceptable parameter values. Inembodiments a larger span may be associated with a higher robustness ofa design (i.e. the design or design parameter results in an acceptableperformance for many scenarios). In embodiments, robustness may be afunction of a span and probabilities associated with each scenario (Pr₁. . . Pr_(j) . . . Pr57).

In embodiments robustness and/or sensitivity of a design and/or designparameters may be determined by determining design and scenarioperformance parameters as depicted in FIG. 60. The performanceparameters may be evaluated via simulation. In some cases, simulationsmay be exhaustive such that each design scenario combination may besimulated to determine performance parameters. In some embodiments, onlya partial set of designs and/or scenarios may be simulated. Based on thesimulation the robustness and/or sensitivity of each design may bedetermined across all the scenarios or a partial set of the scenarios.The results of the robustness and/or sensitivity analysis may beprovided to a user via tables, lists, and/or interactive interfaces suchas tornado diagrams described herein. For example, tables and visualinterfaces may provide information about the performance of a designover various scenarios. The interfaces may provide information regardinghow close the performance of each design was to an acceptable thresholdfor each scenario or a subset of scenarios. The data may be used to geta more complete view of the risks associated with a design andpossibilities to reduce the risks. The data may be used to infer orcalculate the robustness, risk, and/or potential costs associated with adesign. The data may be used to reduce the risk or and/or potentialcosts associated with a design. For example, in some cases, probabilityof some scenarios may be reduced or eliminated with inexpensive orcommon precautions or risk mitigation techniques. A user or the platformmay identify scenarios for which a performance of a design was below athreshold and analyze or prompt the user to analyze possible mitigationtechniques. If inexpensive mitigation techniques are possible the somenegative scenarios for a design may be removed from robustnessevaluations.

In some embodiments, a Pareto analysis may provide for a measure ofrobustness for designs. In embodiments, the Pareto analysis may be usedto determine Pareto optimal designs. As described herein, Pareto optimaldesigns may define the Pareto frontier. In embodiments, robustness ofPareto designs may be determined based on the separation between Paretodesigns.

FIG. 61 shows aspects of measuring the robustness of the design based onPareto analysis. The table FIG. 61 shows data for seven (7) Paretodesigns determined for a set of simulated designs for one performancecriteria of probability of technical success (PoTS). For each design, aPoTS weight can be determined. The PoTS weight indicates the interval ofPoTS for which each design is optimal according to the Pareto analysis.For example, design with DesignID “88” is optimal from a PoTS value of0.022 to 0.274 (corresponding to 2.2% and 27.4% respectively). The rangeof optimality for design “88” is, therefore, 0.252 (25.2%). In anotherexample, design with DesignID “96” is optimal from a PoTS value of 0.274to 0.857 (corresponding to 27.4% and 85.7% respectively). The range ofoptimality for design “96” is, therefore, 0.583 (58.3%). The ranges ofoptimality of the performance parameter are shown in the graph of thefigure. The size of the bar in the graph indicates the range for theperformance parameter that each design is optimal for. The designs withthe largest ranges of optimality (the most robust designs), such asdesigns with Design IDs “88” and “96”, may make good candidates forrecommendation by the system. These designs with the largest range ofoptimality provide the designs that are typically most likely to beselected by a user, such as a decision-maker selecting the study. Forexample, in the case of the design corresponding to Design ID “96”, iftwo or more decision-makers had different weight preferences for PoTS,as long as their preferences were between 0.274 and 0.857, they wouldall prefer design “96” above all other designs. In the selection of thedesigns to recommend, unless there are other factors that would dictatea bias towards the importance of one or more criteria, selecting themost robust designs is often a good starting point for analysis anddesign recommendation. In some cases, Pareto analysis of simulations mayresult in a large number P-designs for initial consideration. In somecases, initial suggestions of P-designs may be limited to the mostrobust P-designs.

In embodiments, robustness and/or sensitivity may be defined withrespect to types of scenarios. In embodiments, scenarios may becategorized based on properties of the scenarios such as theirprobabilities. In one example, scenarios may be categorized into four(4) types of scenarios: Optimistic, Base, Pessimistic, Very pessimistic.In embodiments, a performance score for a design or design parametersmay be determined for each scenario. The scores for each scenario may beused to determine a composite score for each type of scenario (bycomputing an average for example). A composite score may provide ameasure of robustness. The score may provide a measure of a performancefor a design for scenarios that are likely to happen, unlikely tohappen, and the like. Robustness may be determined based on the numberof scenario categories for which a design exhibits acceptableperformance. For example, designs that have acceptable performance forscenarios that are only likely to happen may not be considered robust,while designs that have acceptable performance for scenarios that likelyto happen and unlikely to happen may be considered robust.

Referring to FIG. 1, the analysis facility 108 of the platform 104 mayinclude robustness and sensitivity analysis. The analysis facility 108may include circuits, components, and algorithms for enabling robustnessanalysis. The analysis facility 108 may receive simulation data from thesimulation facility 110 and analyze the simulated data to identifyrobustness of designs. The identified designs may be recommended to auser.

FIG. 62 shows aspects of an apparatus for determining robustness ofdesigns. In embodiments, the apparatus may include a robustness analysiscircuit 6216 which may be part of the analysis facility 108 of theplatform 104. In embodiments, the apparatus may include an outputprocessing circuit 6206 structured to interpret/obtain design data 6202of a clinical trial design. In some embodiments the design data 6202 maybe outputs of simulation data of trial designs. The design data mayinclude simulation data for designs for various scenarios. The outputprocessing circuit 6208 may transform the design data 6202 into a formatsuitable for use by the various circuits in the apparatus. The apparatusof FIG. 62 may further include an evaluation circuit 6208 structured toreceive processed design data from the output processing circuit 6206.The evaluation circuit 620810 may identify robustness 6220 and/or robustdesigns 6218 based on analysis of performance for designs for differentscenarios. In some embodiments, the robustness analysis circuit 6216 mayinclude a Pareto robustness determining circuit 6210. The Paretorobustness determining circuit 6210 may determine Pareto designs fromthe design data 6202 and determine robustness for the Pareto designsbased on the separations of the Pareto designs. The robustness and/orsensitivity of the designs may be compiled into a graphical interfacesuch as a tornado diagram using the graphic generation circuit 6212 andmay be provided to a user with the graphic provisioning circuit 6214.

As shown in FIG. 63, a method for determining robustness of designs mayinclude receiving outputs of a plurality of design simulations for aplurality of scenarios 6302. The method may further include evaluatingthe outputs to determine changes in performance for the designs over theplurality of scenarios 6304. The method may also include providing avisual depiction of a tornado diagram to visualize the differences 6306.

As shown in FIG. 64, a method for determining robustness of designs mayinclude receiving outputs of a plurality of trial design simulations fora plurality of scenarios 6402. The method may further include evaluatingthe outputs to determine Pareto designs 6404. The method may alsoinclude evaluating the range of optimality for each Pareto design 6406and determining a score for each Pareto design based on at least in parton the range of optimality 6408. The method may include recommendingPareto designs above a threshold score 6410.

In some embodiments, one or more optimization algorithms may be used toexplore the global design space or a localized subspace of possibledesigns. Simulated annealing algorithms may be used to explore asubspace of possible designs. In some embodiments, simulated annealingmay be used to explore the design space around an initial selected trialdesign to determine if there are any additional design options near theselected design that provide an improvement to one or more criteria orparameters. Simulated annealing may reduce the number of designs thatare simulated while providing high confidence that optimum or nearoptimum designs are determined.

In embodiments, design simulations may be non-exhaustive and theplatform may simulate a partial set of possible design options. When apartial set of possible design options for a design criteria issimulated best/optimal designs may be missed. When only partial set ofdesign options has been simulated, designs of interest (such as designswith the best and/or optimal performance for the set of simulateddesigns) may be identified (such as by a user or by other components ofthe platform), simulated annealing may be used to search for additionaldesigns that may have similar or better performance than the designs ofinterest. In embodiments, when only a partial set of design options hasbeen simulated, regions of interest (such as regions of the performancespace that are identified as having designs of interest) may beidentified (such as by a user or by other components of the platform),simulated annealing may be used to search for additional designs thatmay have similar or better performance than the designs of interest.

Simulating annealing of trial designs may involve an initial startingdesign and iterations that consider neighboring design options. Adaptivelogic may be used to move the system between different neighboringdesign options. Adaptive logic may control which parameters of thedesign options are modified, how much they are modified, conditions fortaking different paths, conditions for retreating towards the initialdesign, conditions for cooling schedules, and the like. Adaptive logicmay predict which parameter modification may results in an improvementin performance compared to the initial design. In embodiments,predictions may be based on historical data. Previous simulation datamay be used to generate ML and/or AI models to predict the effects ofchanges of design on performance. For each modification from the initialdesign, the design modification may be simulated to determine theperformance of the design to determine if the modification resulted inan improved design option. Changes in performance may be used by thecontrol logic to determine the path of exploration and other parametersof simulated annealing.

Referring to FIG. 1, the search/exploration component 130 of thesimulation facility 110 of the platform 104 may include components forsimulated annealing. The search/exploration component 130 may includecircuits, components, and algorithms for enabling simulated annealing.The search exploration component 130 may interact with the models 126and engines 128 components to explore design space. In embodiments theanalysis facility 108 may provide analysis data to simulated annealingcomponents to identify designs or regions of interest. Thesearch/explorations component 130 may use simulated annealing todetermine designs around designs of interest and/or in or around regionsof interest and simulate the designs. The analysis facility 108 mayprovide analysis of the simulated designs to determine parameters (suchas cooling cycles, parameter changes, directions, and the like) forsimulated annealing.

In embodiments, simulated annealing may be used in a workflow whereinitial design simulations are selected to provide a coarserepresentation/overview of the performance space of the design options.The coarse representation may be used to identify designs or regions ofthe performance space, scenario space, and/or design space of interest.The designs or regions of interest may be used as initial startingpoints for simulated annealing to search for designs near the identifieddesigns or in the regions of interest that have improved performancecompared to the initial designs. In some embodiments, initial coarsedesign simulation may represent 50% or 30% or less of the total designoptions for a criteria. The use of coarse initial design simulation mayreduce initial simulation time and resources. In embodiments, thedesigns of interest or the regions of interest from the initialsimulations may be determined by a user via user interface. Inembodiments, the designs of interest or the regions of interest from theinitial simulations may be determined by other elements of the system.For example, designs of interest that can be identified using Paretoanalysis, convex hull analysis, and the like. Simulated annealing may beused to fill in gaps between initial simulated designs.

In embodiments, simulated annealing analysis may be configured to fillgaps in a convex hull within a CHP cluster. Simulated annealing may beconfigured to reduce simulation runs required by the Cartesian productapproach. Simulation may start with a coarse cartesian grid (orreplications of trials of random samples of designs randomly, possiblystratified) as input and incrementally develop P-designs and CH-designsthat are identical or close to the P-designs and CH-designs of the fullCartesian sample using simulated annealing.

Simulated annealing may be configured to find designs that are optimalfor given weights or a design that is nearest in performance tospecified desired criteria. In some embodiments, the simulated annealingmay use a weighted sum of squares or of absolute differences as thedistance from the desired point to iterate to a design if there is afeasible design in a specified elliptical or box neighborhood around thepoint. The simulated annealing may be configured to use starting pointsthat are designs closest to designs that are in the criteria space. Inembodiments, the simulated annealing algorithm/engine may explore thedesign space around a criteria by exploring the effects of alteringparameters of a design. Simulated annealing may be configured to exploreall the parameters of a design or preferentially manipulate or explore asubset of the parameters. In some embodiments, users may specifypreferences with respect to which parameters to prioritize for theexploration using simulated annealing. In some cases, the user mayspecify which directions the simulated annealing should explore thedesign space. The constraints may be based on which areas of the designspace already have many designs, for example. In embodiments, historicaldata related to simulated annealing search may be used to prioritize oneor more design parameters for the search using the algorithm.

In embodiments, inputs to simulated annealing may include a weightvector for criteria, an objective function specification (e.g., normalvector for CHFs), design variable ranges (discretized) numeric orcategorical, design simulation engines (with control of a number ofsimulations and in future feedback of intermediate results as enginedecreases replications at inferior designs to exploit simulationefficiency), engines for design simulations or other engines equippedwith interfacing wrappers, set of starting designs from which simulatedannealing will iteratively attempt to improve using probabilisticsearch. Inputs may further include cooling schedules with defaults,constraints on design variables (e.g., upper and lower bounds, rules ofinadmissible combinations and the like). In embodiments, outputs mayinclude parameters and criteria values for best design found, bestdesign for each start, visualization of paths, cooling schedules,visualization through parallel designs interface, and the like. Theoutput of the simulated annealing analysis may be used to update the setof CH designs and P-designs. The simulated annealing analysis may beconfigured and/or modified using one or more interactive interfaces(such as from feedback from card interface, heatmap interface, tornadodiagram interface).

In some embodiments, a simulated annealing algorithm/engine may beconfigured for multicriteria objectives where no weights for performancecriteria are specified and the algorithm/ending may search for Paretopoints directly. In some embodiments, the simulated annealingalgorithm/engine may start a search with P-designs and/or siblings ofP-designs. In embodiments, the simulated annealing algorithm/engine maybe parallelized. Parallelization may be configured based on convex hullfacets and/or different data sets which can be computed in parallel. Inembodiments, the simulated annealing algorithm/engine may include boundsand/or improvement cut-off criteria in the search. In embodiments, thesimulated annealing algorithm/engine may use a flexible grid structureand may use different step sizes when exploring the design space. Inembodiments, the step/grid size may be initially coarse (relativelylarge steps) and set to finer logic (relatively smaller steps) as thedesign space is explored. In embodiments, search algorithms/engines mayinclude genetic and/or integer programming algorithms/engines. In someembodiments, smart Monte Carlo methods (including as described herein)may be further used to reduce the number of simulated designs.

FIG. 65 shows aspects of an apparatus for determining designs usingsimulated annealing. In embodiments, the simulated annealing component6502 may be part of the simulation facility 110 of the platform 104. Thesimulated annealing analysis component 6502 may receive data forsimulated designs 6508. The simulated design may identify designs ofinterest or regions of interest that may be used as a starting point forsimulated annealing analysis. The parameter selection circuit 6506 ofthe simulated annealing analysis component 6502 may identify parametersof a design that is neighboring or close to the design of interest or isin the region of interest. In embodiments, parameter selection may bedefined by a user from user input 6516 and/or based on input from othercomponents of the platform. Parameter selection circuit 6506 maydetermine designs parameters from an objective function 6518, coolingschedule definitions 6514, and other data. Objective function 6518 mayinclude data from the analysis facility 108 and may provide dataregarding locations of Pareto design, CH designs, facets of convex hull,normals of facets, distance between CH designs and Pareto designs, andthe like. Parameter selection circuit 6506 may identify feasible designsfrom the design space 6512 that have the identified parameters. Theparameter selection circuit 6506 may verify that the parameters of thedesign to be evaluated are feasible under defined criteria based on thedesign space 6512 data. Once the design to be simulated is definedaccording to the parameter selection circuit 6506 the design definitionmay be provided to engines component 128 of the simulation facility 110for simulation and the performance data 6520 of the simulated design maybe received after simulation. The adaptive control circuit 6526 mayevaluate the performance data 6520 to determine the next direction, stepsize, set of parameters to manipulate, and the like. The adaptivecontrol circuit 6526 f may identify trends and correlations betweenchanges in parameters of designs and the resulting performanceparameters of the design. The trends and correlations may be used to bythe parameter selection circuit 6506 to identify new design options toevaluate. The adaptive control circuit 6526 may further interact withthe cooling circuit 6504 to determine if the selection of parametersshould return to a previous state. The simulated annealing analysiscomponent 6502 may provide search data 6524 and data related to pathsand changes in parameters that may be analyzed and/or visualized byusers. The search data 6524 may be used to change or update objectivefunctions 6518, cooling schedule 6514 and other settings related to thesimulated annealing analysis component 6502.

FIG. 66 shows an example flowchart for simulated annealing which may beimplemented by the simulated annealing component 6502. Simulatedannealing may start with a definition of parameters 6602 and/ordetermination of adjacent combinations 6604 for a design to besimulated. The definition of parameters may include receiving designparameters 6602 or determining parameter variations to a design toidentify a new adjacent design 6604. The parameters of the design to besimulated may be tested for exclusion criteria 6606. In some cases, theparameters may generate an invalid combination for a design for acriteria of the study. If the design is excluded 6610, the exclusion maybe recorded in an exclusion log 6608 and a new set of parameters may bedetermined 6602, 6604. If the design is not excluded, the design may besearched in a database 6612 of previously simulated designs (such asfrom previous design studies). If the design is found in the database6614, the data for the design may be retrieved and added to the log 6614and new parameters may for a new design may be determined 6602, 6604. Ifthe design is not found in the database, the design may be simulated6618 and the performance of the design may be evaluated 6620. Based onthe performance, new designs may be selected 6602, 6604 and theprocesses repeated.

As shown in FIG. 67, a method evaluating designs using simulatedannealing may include identifying an initial design 6702. The method mayfurther include varying the parameter of the initial design to generateparameters for a second design 6704. The method may include simulatingthe second design 6706 and analyzing the simulation data to determineparameters for a third design 6708.

As shown in FIG. 68, a method for evaluating designs using simulatedannealing may include obtaining trial design simulations 6802. Themethod may further include identifying an initial design from the trialdesign simulations 6804. The initial design may be an optimum designwith respect to the trial design simulation. The method may includepredicting performance for variation of the initial design 6806.Predictions may be based on historical data such as previoussimulations. AI and ML algorithms may be used to determine how changesin parameters may affect the performance of a design. Based on thepredictions, parameters for a new design may be identified. The newdesign may be a design that has favorable predictions such as animprovement in one or more performance parameter values compared to theinitial design. The method may include simulating the new design 6810and identifying a second new design for simulation 6812. The second newdesign may be identified based on the simulation results. For example,if the simulation results matched the predictions the second new designmay be on the same trajectory from the initial design as the new design.

In embodiments simulated annealing includes consideration and analysisof performance, design, scenario, and criteria spaces. Simulatedannealing analysis searches for designs that show improvements in theperformance space. Searching comprises generating variation in thedesign parameters (design space) and scenarios (scenario space)parameters of an initial design. The performance, design, and scenariospaces are defined according to the criteria space definitions.

Referring to FIG. 69, embodiments of the present disclosure may employDelaunay triangulation, or other interpolation methods, e.g.,clustering, to reduce the number of simulated clinical trial designs. Inparticular, the number of initial simulations may be non-exhaustive andDelaunay triangulation may be used to determine what additional designsshould be simulated and/or which areas of the design space should beexplored (such as with simulated annealing). For example, an embodimentof a method that uses Delaunay triangulation may start with a number ofinitial clinical trial designs for which the design parameters and/orperformance parameters are known, either through simulation orhistorical data. The method may construct a piecewise linear criterionsurface via Delaunay triangulation, wherein each point on the surface,minus the initial designs, represents interpolated criteria for possibledesigns. Thus, the criteria for a clinical trial design may bedetermined (estimated) before the design is simulated.

Accordingly, the time required to perform simulated annealing may bedecreased by testing variations of a clinical trial design withouthaving to simulate the variations by locating the variations on thesurface. Interpolation may be computed using the barycentric coordinatesof a point within its enclosing simplex. The surface may be used togenerate visualizations of the weighted criteria functions over thedesign space. The visualizations may include a weighted criteria surfacegenerated via the weighted sum of the individual criteria surfaces,which may provide for rapid estimation of the design value for a largeset of criteria weights. Embodiments may use linear programming ornetwork formulation as the “simplex finder” for a given design point.The surface may also be used to determine most promising and leastpromising directions or parameter variations in simulated annealingtherefore reducing the number of simulations. Use of the criterionsurface may provide for the early detection that a clinical trial designis not likely to be a Pareto design and, therefore, simulation of theclinical trial design may be skipped.

In particular, embodiments of the current disclosure may use a simulatedannealing engine to leverage the criteria values from past clinicaltrial designs that have been simulated for a scenario vector to estimatedesign performance under an adjacent scenario. As such, some embodimentsmay take advantage of the fact that: 1) the edges in a Delaunaytriangulation contain all shortest paths between any two design points;and/or 2) minimum spanning trees of all subsets of the design points aresubgraphs of the Delaunay triangulation.

For example, consider a set of clinical trial designs that have beensimulated and have known performance parameter values. The clinicaltrial designs may be treated as a scatter of points in the K dimensionaldesign space of design vectors (e.g., K=5). Each clinical trial designmay be associated with its performance parameter vector of dimension J(e.g., J=3). A Delaunay triangulation of these clinical trial designvectors may be constructed, wherein the surface of any criterion at anypoint is the interpolation of the criterion values of the K Delaunaysimplex vertices containing the point. The interpolation may be computedusing the barycentric coordinates of the point within its enclosingsimplex. The weighted criteria surface is then the weighted sum of theindividual criteria surfaces. As will be appreciated, this approach mayprovide for rapid estimation of a design's values for a large set ofperformance parameter weights. As will be further appreciated, Delaunaytriangulation also has the advantage of creating simplexes that are not“long and skinny” so that vertices are “reasonably” close to anyinterior point. This is particularly true where, as in some embodimentsof the present disclosure, the design points belong to a rectangulargrid. Embodiments of the present disclosure may utilize linearprogramming or network formulation as the “simplex finder” for a givendesign point. A cache of recent simplexes since, apart fromvisualization may then be used to quickly approximate the criterionvalue.

Accordingly, as shown in FIG. 69, a method 6900, in accordance with thecurrent disclosure, may include obtaining a first plurality of clinicaltrial designs with determined performance parameters 6910; andgenerating a criterion surface 6912, also referred to herein as aperformance surface, based at least in part on the first plurality ofclinical trial designs. As discussed herein, the points on theperformance surface represent interpolated performance parameters for asecond plurality of clinical trial designs (which may not have beensimulated, as described herein). One or more clinical trial designs maythen be evaluated based at least in part on the performance surface6914. In certain aspects, the performance surface may be based at leastin part on Delaunay triangulation, though other methods of interpolatinga surface may be used. In certain aspects, evaluating may includesimulated annealing 6916. The method 6900 may further include generatinga visualization based at least in part on the criterion surface 6918. Inembodiments, the visualization may be of weighted criteria functionsover the corresponding design space. In embodiments, generating theperformance surface may include interpolation based at least in part onthe barycentric coordinates of a point 6920. In embodiments, theevaluating may further include determining that a clinical trial designof the second plurality is not a Pareto design 6922.

Turning to FIG. 70, an apparatus 7000 for implementing one or moreaspects of the method 6900 is shown. The apparatus 7000 may form part ofone or more computing devices in the platform 104, to include thecomputing resources 150. The apparatus 7000 may include a designprocessing circuit 7010 structured to interpret clinical trial designdata 7012 corresponding to a first plurality of clinical trial designswith determined performance parameters. The apparatus 7000 may furtherinclude a surface circuit 7014 structured to generate a performancesurface data object 7016 based at least in part on the clinical trialdesign data 7012. The performance surface data object 7016 may includedata points representing interpolated performance parameters for asecond plurality of clinical trial designs. The apparatus 7000 mayfurther include a performance surface provisioning circuit 7020structured to transmit the performance surface data object 7016.

Referring now to FIG. 71, a non-limiting embodiment of therecommendation component/system 7100 (also referred to herein asrecommendation system architecture) is shown. In embodiments, therecommendation component 7100 may be, and/or be part of, therecommendation component 122 (FIG. 1). In other embodiments, therecommendation component 7100 may be a separate system from therecommendation component 122. The recommendation component 7100 may beconfigured to identify and provide one or more clinical trial designsfor recommendation to a user via an interface, e.g., interface of a userdevice 102. In some embodiments, the recommendation component 7100 mayreceive feedback from a user via the interface of a user device 102 forevaluating recommended designs and revise or update recommendationsbased on the feedback. As shown in FIG. 71, the recommendation component7100 may include a recommendation database 7110, a simulation database7112, and/or a recommendation algorithm/engine 7114.

The trial simulation database 7112 may form part of the data facilities138 and be a large repository of previous, current, and/or selectedclinical trial design simulations. The trial simulation database 7112may include simulations, as described herein, merged from differentdatabases, groups, users, and the like. The trial simulation database7112 may include data related to each simulation, such as engines usedto run the simulation, date, time, and/or the like. In embodiments, thetrial simulation database 7112 may include input data such as: idnumber, version, scenario id, design id, user id associated with aclinical trial design, the running status, number of interim analyses,time units, performance of events observed, treatment arm information,treatment control name, and/or the like. In embodiments, the trialsimulation database 7112 may include output data such as accrualduration, average power, events data, net present value, insufficientcount data, follow-up time data, expected net present value, probabilityof efficiency, probability of favorability, probability of futility,probability of success, study cost, study duration, time required,discounted study cost, total sales, a score, a total score, and/or thelike. The inputs and/or outputs may be organized in a hierarchy thatincludes labels and/or other identifiers that label the items aspertaining to scenarios, clinical trial designs, primary criteria,secondary criteria, stimulation control, and the like. The trialsimulation database 7112 may include temporal data for each simulationand may include data related to the beginning phase of a clinical trialdesign, the middle of a clinical trial design, progress data of virtualpatients, and/or the like. In some cases, the trial simulation database7112 may include raw simulation data from each simulation run. In somecases, the simulation database 7112 may include summary recordsassociated with each clinical trial design simulation and includeaverages, endpoints, overall statistics, and/or the like. The trialsimulation database 7112 may include data that relates each clinicaltrial simulation to the design space, scenario space, criteria space,and/or performance space, as described herein.

The recommendation database 7110 may include a subset of the trialsimulation database 7112 that has been analyzed or flagged to beapplicable to design criteria.

The recommendation engine 7114 may include and/or interact with one ormore components and/or algorithms/engines, e.g., a Pareto engine 7118, aconvex hull engine 7120 and/or any other engines/components describedherein, for simulation, global optimization, visualization, analysis ofclinical trial designs, control, and/or the like. For example, therecommendation engine 7114 may interact with, e.g., exchange data withand/or invoke procedure calls to, the simulation facility 110 (FIG. 1).For example, embodiments of the recommendation engine 7114 may utilize asimulated annealing component/algorithm/engine 7116 which may beprovided by the search/exploration component 130 (FIG. 1) of thesimulation facility 110. In embodiments, the recommendation engine 7114may include and/or interact with a primary algorithm 4510, as describedherein, that controls and/or monitors the workflow of the algorithmsand/or engines 7114, 7116, 7118, and/or 7120.

In embodiments, the Pareto algorithm/engine 7118 and/or the convex hullalgorithm/engine 7120 may be run or executed sequentially such that theoutput of the Pareto algorithm/engine 7118 may be an input to the convexhull algorithm/engine 7120. In this scenario, the Pareto engine 7118 maybe used to first identify Pareto designs (also referred to herein as“P-designs”) from the design space (which may be a subset of the designspace), and the convex hull algorithm 7120 may further separate theP-designs and identify convex hull designs (also referred to herein as“CH-designs”), which may be a subset of the P-designs. In embodiments,the convex hull engine 7120 may be the first executed engine and mayidentify a set of CH-designs from the design space, wherein the Paretoengine 7118 may be used to further identify P-designs from the set ofCH-designs. In embodiments, the convex hull engine 7120 may beconfigured to quickly update the identified CH-designs when new designsare introduced as inputs to the convex hull engine 7120. The set ofidentified CH-designs may be augmented incrementally by the Paretoengine 7118 as new designs are identified/simulated and added to thedesign space.

In embodiments, the Pareto engine 7118 may be executed without theconvex hull engine 7120, wherein the outputs of the Paretoalgorithm/engine 7118 may be used for design recommendations. In someembodiments, the convex hull engine 7120 may be executed withoutexecuting the Pareto engine 7118, wherein the outputs of the convex hullengine 7120 may be used for design recommendations.

In embodiments, the recommendation engine 7114 may be configured toprovide a user with a limited number of recommended designs. Therecommendation engine 7114 may provide recommendations that are a subsetof the P-designs or the CH-designs. In some cases, the recommendationengine 7114 may be configured to limit the number of designs recommendedto between about five (5) and about nine (9) designs. Recommendeddesigns may be presented in small sets (such as between about five (5)and about nine (9) designs), allowing a user to compare the designs inthe set. The set of recommended designs may be interactively augmentedor updated based on user input or feedback. For example, therecommendation algorithm 7114 may present a set of initial recommendeddesigns and ask a user to select a favorite design. Based on thefavorite design, the recommendation engine 7114 may augment a next setof recommended designs. For example, based on the selection of onedesign, the engine 7114 may further present siblings of the selecteddesign and/or designs that are dominated by the design.

Referring now to FIGS. 72 and 73, in embodiments, the recommendationengine 7114 may determine clinical trial designs 7210 to recommend (alsoreferred to herein as “a set of recommended designs” or “recommendeddesigns”) to the user by processing a set of simulated designs 7212,which may be retrieved from the database 7112. Processing of thesimulated designs 7212 may involve use one or more algorithms/engines,such as the Pareto engine 7118 and/or convex hull engine 7120. Forexample, in one configuration, the set of clinical trial designs 7212may be first processed using the Pareto engine 7118 to identify a set ofPareto designs 7214 (P-designs) and/or a set of dominated designs 7216.As represented in FIG. 73 by the inverse triangle, in embodiments, theset of Pareto designs 7214 may be much less than the set of all designs7212, e.g., 10× or 100× smaller, the set of convex hull designs 7218 maybe smaller than the set of Pareto designs 7214, and the set ofrecommended designs 7210 may be smaller than the set of convex hulldesigns 7218. For example, the set of Pareto designs 7214 may be furtherprocessed using the convex hull engine 7120 to identify, from the set ofP-designs 7214, convex hull designs 7218, wherein the convex hulldesigns 7218 are, generally, Pareto designs 7214 that can be reached byweighting criteria as described herein. In embodiments, non-reachablepareto designs 7222 may not be considered for use by the convex hullengine 7120 and/or recommendation.

Referring to FIG. 74, in embodiments, the design recommendation engine7114 may generate one or more outputs 7410, including a list or a set ofthe recommended designs 7210. The list of recommended designs 7210 maybe provided with criterion values 7412, scenario parameters 7414, and/ortrial design parameters 7416. A non-limiting example of a list ofrecommended designs is shown in FIG. 75. As shown, the list may includedesign ID, power, costs, and/or duration for each listed design. Theterm “power”, as used herein with respect to a clinical trial design mayrepresent a measure of one or more properties and/or statistics of theclinical trial, e.g., statistical power. For example, power may providean indication of how many patients are required to avoid a type I (falsepositive) or type II (false negative) error.

Inputs 7418 to the recommendation engine 7114 may include the clinicaltrial design results 7212, wherein the engine 7114 generates the Pareto7214 and convex hull 7218 designs via the corresponding engines 7118 and7120. In some embodiments, however, the Pareto designs 7214 and/or theconvex hull designs 7218 may be fed to the engine 7114 as inputs 7418.The inputs 7418 may also include any other type of output from thePareto 7118 and/or convex hull 7110 engines (facets, normal, etc.). Inembodiments, the inputs 7418 to the recommendation engine 7114 may alsoinclude the set or a subset of all the designs simulated 7212 inaddition to the P-designs 7214 and/or CH-designs 7218. Inputs 7418 mayalso include user settings 7420 and/or parameters 7422, such as thenumber of recommendations the recommendation engine 7114 should provide.The recommendation engine 7114 may receive user selections and otherinputs 7418 that may provide guidance to the engine 7114 as to whichdesigns are preferred by the user or which other designs the user wantsto explore.

In embodiments, the algorithm/engine 7114 may generate or outputvisualizations and/or interfaces (collectively shown as 7424) to comparetwo or more recommended designs 7210. Non-limiting examples of thevisualizations 7424 are depicted in FIGS. 76 and 77 and may beconfigured for performing sensitivity analysis on the recommendeddesigns 7210, as described herein. Visualizations 7424 may also includeother types of graphs and/or other visual representations that depictpreference weights regions (polygons in three (3) criteria models),barycentric coordinate graphics, and/or the like. As shown in FIG. 76,visualizations may depict relationships between recommended designs 7210with respect to weightings (W1—power and W2—costs) for performancecriteria. As will be understood, the numbered polygons in FIG. 76represent the range of weighting values for each of the recommendeddesigns 7210, which may be optimal. As shown in 77, a visualization maydepict the relationship of recommended designs, e.g., sixteen (16)different designs (numbered “1-6”, “8-10”, “13”, “15”, “19” “54”, “63”,“69”, and “120”), with respect to weightings 7710 for performancecriteria. Polygons may be used to represent the range of weightingvalues for each of the recommended designs which may be optimal.

The recommendation engine 7114 may also output lists or sets of designs,referred to herein as “related designs” 7426 (FIG. 74), that are closeto the recommended designs 7210 in the criterion space (which may or maynot be P-designs or CH-designs). Related designs 7426 may be determinedusing various distance measures. For example, one distance measure maybe related to the steps needed for a simulated annealing algorithm 7116(FIG. 71) to go from one design to another. In embodiments, therecommendation engine 7114 may provide recommendations for designs 7210(based on the Pareto 7118 and/or the convex hull 7120 engine outputs)and allow a user to compare and analyze the recommended designs 7210(sensitivity analysis, weigh graphs, etc.). The recommendation engine7114 may provide lists of twin or sibling designs 7428 (FIG. 74) thatare related to a selected design and show/highlight different types ofdesigns that are available or close to a selected/recommended design.

In embodiments, design siblings 7428, and/or other different clinicaltrial designs that have similar performance criteria, may have differentcomplexity. In some embodiments, types of clinical trial designs may bearranged and/or marked according to the complexity, ratings, historicalpreference, and/or the like. In some cases, clinical trial designs maybe arranged in a hierarchy according to a preference such that, forexample, designs that have lower complexity for a performance criteriaare provided first. For example, in a case where multiple clinical trialdesigns have the same or nearly the same performance criteria, themultiple clinical trial designs may be ordered based on the propertiesof the designs when providing recommendations.

In embodiments, the recommendation algorithm/engine 7114 may includelogic to reduce the set of CH-designs 7218 by a user-specified number bydropping CH-designs within the set 7218 with the objective of minimizingthe maximum reduction of criteria values over the weight space. Therecommendation engine 7114 may include logic to expand the CH-design set7218 by choosing subsets of Pareto designs 7214 that are closest to theconvex hull facet of the CHF cluster (facets may be Delaunaytriangulations as described herein). The recommendation engine 7114 mayinclude logic to fill gaps between recommended designs 7210. Forexample, Pareto designs 7214 in CHF clusters may be selected to filllarge gaps (e.g., large facets and/or distances from a recommendeddesign and a target point on the facet according to different metrics(e.g., multiple of criteria value differences (ε₁, ε₂, ε₃, . . . ))).The clusters may also be based on default and/or user-definedparameters, and/or average overall weights in a facet of the distancefrom a target point. The recommendation engine 7114 may include logic tocalculate distances in design space to search for designs that aresiblings, e.g., close in criterion space but distant in design.

In some embodiments, the recommendation engine 7114 may provide initialrecommendations that cover all possible weightings of performancecriteria. In such embodiments, the recommended designs 7210 may serve asanchor designs that facilitate further exploration of the simulateddesigns. Anchor designs may serve as initial points for design searches,e.g., simulated annealing, as described herein. The recommended designs7210 may be designs that best approximated the performance (with respectto performance criteria) of the CH-designs 7218 and/or P-designs 7214.In embodiments, one or more cluster designs 7220 (FIG. 72) may beassociated with each of the CH-designs 7218. The cluster designs 7220may be generated by the Pareto engine 7118. In embodiments, the clusterdesigns 7220 may be used to provide rapid recommendations when more thana threshold number, e.g., twenty-four (24), of recommended clinicaltrial designs 7210 are desired, and/or when designs in a certain rangeof weights are desired. In embodiments, the cluster designs 7220 mayinclude all of the Pareto designs 7214.

As will be understood, embodiments of the recommendation engine 7114 maypresent different types of designs within the recommended set of designs720 that are similar in performance criteria. In certain aspects, thedifferent types of designs may have similar performance criteria butdifferent design parameters that may be more favorable for certainsituations.

As will be further understood, in some embodiments, simulations ofdesigns may not be exhaustive, i.e., the set of initial designs 7212 maybe incomplete. For example, not every possible combination of clinicaltrial designs may be initially simulated, and/or a partial set of allclinical trial design combinations may be simulated and processed usingone or more of the Pareto, convex hull, and recommendationalgorithms/engines. In such cases, when a recommended design 7210 isprovided, it may be true that a better, i.e., more optimal, design forthe desired performance criteria exists in the space. In some cases,when a design is recommended 7212, the recommendation engine 7114(and/or primary algorithm 4510, may further explore if there are designsthat have better or similar performance to the recommended designs 7210that have not been simulated. In embodiments, the simulated annealingalgorithm/engine 7116 may be used to explore the design space aroundrecommended 7210 and/or selected designs.

Accordingly, turning now to FIG. 78, a non-limiting example of a method7800 for recommending clinical trial designs in accordance with thecurrent disclosure is shown. The method 7800 may include obtainingclinical trial design simulation results for a set of clinical trialdesigns 7810, and determining a set of Pareto designs 7812 based atleast in part on the clinical trial design simulation results and one ormore performance parameters of the kind described herein. The method7800 may further include determining a set of convex hull designs 7814based at least in part on the clinical trial design simulation results7212 and/or the Pareto designs 7214. The method 7800 may further includedetermining a set of recommended designs 7816 based at least in part onthe set of Pareto designs 7214 and/or the set of convex hull designs7218. In embodiments, the method 7800 may further include transmittingthe set of recommended designs 7818.

Referring to FIG. 79, in embodiments, the method 7800 may furtherinclude filtering clinical trial designs which are dominated by Paretodesigns 7910. The method 7800 may further include filtering clinicaltrial designs which are dominated by convex hull designs 7912. Inembodiments, determining the recommended designs 7210 may includedetermining that at least one of the recommended designs 7210 is withinan epsilon-distance from at least one of the Pareto designs 7914. Inembodiments, determining the recommended designs 7210 may includedetermining that at least one of the recommended designs is within anepsilon-distance from at least one of the convex hull designs 7916. Inembodiments, the method 7800 may further include identifying differentdesign types in the set of Pareto designs 7918. As shown in FIGS. 78 and79, the Pareto designs 7214 may be determined prior to determination theset of convex hull designs. In such embodiments, the convex hull designs7218 may be derived from the Pareto designs 7214 such that each of theset of convex hull designs 7218 is one of the Pareto designs 7214, andsuch that at least one of the recommended designs 7210 is a convex hulldesign 7218. As shown in FIG. 80, in embodiments, the convex hulldesigns 7218 may be determined prior to determination of the Paretodesigns. In such embodiments, the Pareto designs 7214 may be derivedfrom convex hull designs 7218 such that each of the set of Paretodesigns 7214 is a convex hull design 7218, and such that at least one ofthe recommended design 7810 is a convex hull design 7218.

Returning back to FIG. 79, the method 7800 may include identifying 7922a number of clinical trial designs in the Pareto designs 7214, where theconvex hull designs 7218 are determined 7814 when the number isgreater-than-or-equal to a threshold 7924.

Referring now to FIG. 81, an apparatus 8100 for implementing the method7800 is shown. The apparatus 8100 may include a results processingcircuit 8110, a Pareto evaluation circuit 8112, a convex hull evaluationcircuit 8114, a recommendation evaluation circuit 8116, and/or arecommendation evaluation provisioning circuit 8118. The resultsprocessing circuit 8110 is structured to interpret/obtain 7810 theclinical trial design simulation results 7212. The Pareto evaluationcircuit 8112 is structured to determine 7812 the Pareto designs 7214based at least in part on the clinical trial design simulation results7212 and one or more performance criteria, as described herein. Theconvex hull evaluation circuit 8114 is structured to determine 7814 theconvex hull designs 7218. The recommendation evaluation circuit 8116 isstructured to determine 7816 the recommended designs 7210. Therecommendation provisioning circuit 8118 is structured to transmit 7818the recommended designs 7210. The apparatus 8100 may further include oneor more filtering circuits, collectively represented by 8120, thatperform filtering of the clinical trial designs 7212, Pareto designs7214, and/or convex hull designs 7218, as described herein.

Referring now to FIG. 82, a non-limiting example of a simulation queue8210 for management and optimization of clinical trial designs 8212 isprovided. The queue 8210 and/or corresponding methods described hereinfor operating the queue 8210, may implemented by the simulation facility110, analysis facility 108, and/or other components of the platform 104(FIG. 1). As shown in FIG. 82, the queue 8210 may have an entrance 8214,where yet to be simulated clinical trial designs 8212 are accepted, andan exit 8216, where the next to be simulated clinical trial design 8212is pulled from.

In embodiments, simulations of clinical trial designs 8212 may beexecuted according to input queues, e.g., queue 8210, of individualsimulation runs 8212, as described herein. Queues may be organized basedon factors associated with the simulation runs, expected outputs of thesimulation runs, and/or relationships between simulation runs.Non-limiting examples of such factors may include similarity, priority,costs, and/or complexity. The relationships may be discovered/identifiedusing machine learning, e.g., artificial intelligence. For example, thesimulation runs in a queue may be organized based on time required torun the simulations. In another example, the simulation runs in thequeues may be organized to process the most promising designs first,thus facilitating quick access to most the promising designs.

Most promising designs may be identified from historical data and/ormachine learning. A most promising design may be a clinical trial designthat has a moderate-to-high chance, e.g., greater than 50%, of being aglobal optimal for a particular set of performance criteria. Historicaldata may be acquired from one or more data sources in the data facility138 (FIG. 1). In one example, simulation runs in the queues may beorganized based on user identified parameters. In one instance,simulation runs in the queues may be populated to provide an initialnon-exhaustive sampling of the design space to provide of an overview ofthe performance of the clinical trial designs. The initial results maybe used to populate queues for designs that are near designs that are inthe desirable areas of the performance space. Simulated annealing, whichmay be provided by the search/exploration component 130 (FIG. 1) may beused to populate the queues with simulation runs for designs that arenear initial simulated designs that are determined to be promising. Theorder of simulation runs in the queues may be revised based on resultsfrom initial simulations. Queues may also be organized to prioritizesimulation runs to provide real-time results.

In certain aspects, queues, e.g., queue 8214, may be organized based ontime and/or costs. For example, results of a first simulation run may beneeded before results of a second simulation run. Additionally, asimulation run may be given a lower priority in a queue, and/orscheduled, so that it runs on a processing system during off-peak hours,thus, lowering costs. Queues may also be organized to execute simulationruns across different hosting providers, e.g., across multiple cloudcomputing systems. For example, higher priority simulation runs may bequeued to run on a first cloud computing system, where the hostingprovider charges a premium price for fast results, and lower prioritysimulation runs may be queued to run on a second cloud computing system,where the hosting provider charges a non-premium price for slowerresults. In certain aspects, queues may be organized by customer and/oracross customers. For example, simulation runs for a first customer maybe prioritized over simulation runs of a second customer. Queues mayalso be organized based on workload and/or work type. Queues may also beorganized to assign simulation runs to either a binary computing systemor a quantum computing system. For example, simulation runs that fallinto the bounded error, quantum, polynomial time class, but outside ofP, may be assigned to a quantum computing system, while P class problemsmay be assigned to a binary computing system. Artificial intelligence,e.g., machine learning, may also be used to organize queues, to includepopulating and distributing simulation runs. For example, inembodiments, a neural network training set may include a variety ofclinical trial designs and whether they were previously selected asbeing a global optimum design for a particular scenario. Using such ascenario, the neural network may learn to identify promising clinicaltrial designs and prioritize them in one or more queues. In embodimentsqueue organization may be based at least in part on metadata associatedwith the models and/or engines. Metadata may include data regarding whatengines, run times, resources, and the like are necessary forsimulation.

While FIG. 82 depicts a single queue 8210, embodiments of the currentdisclosure may include multiple queues executing on multiple machines,e.g., computing resources 150 (FIG. 1).

Illustrated in FIG. 83 is a method 8300 for management and optimizationof clinical trial designs. The method 8300 may include determiningsimulation runs for a trial design study 8310. The method 8300 mayfurther include selecting a subset of the simulation runs 8312. Themethod 8300 may further include populating a simulation queue with thesubset of the simulation runs 8314. The method may further includeexecuting the subset of simulation runs according to the simulationqueue 8316.

Illustrated in FIG. 84 is an apparatus 8400 for management andoptimization of clinical trial designs. The apparatus 8400 includes atrial design processing circuit 8410 structured to interpret trialdesign study data 8412. The apparatus 8400 includes a first evaluationcircuit 8414 structured to execute simulation runs 8416 of clinicaltrial designs defined, in part, by the trial design study data 8412. Theapparatus 8400 includes a ranking circuit 8418 structured to, inresponse to executing the simulation runs 8416, rank the simulation runs8416 according to expected performance, i.e., generate rankings 8420 forthe simulation runs 8416. In certain aspects, the expected performancedata may be based on data derived from a database of simulated designs.The apparatus 8400 includes a simulation populating circuit 8422structured to populate a simulation queue 8210 according to thesimulation run rankings 8420. The apparatus 8400 includes a secondevaluation circuit 8426 structured to execute simulation runs from thesimulation queue 8210. In embodiments, the rankings 8420 may be revisedbased at least in part on the outputs of simulated runs.

As described herein, simulations of trial designs may use simulationengines. Accordingly, referring now to FIG. 85, a marketplace 8510 forsimulation engines 8512 is shown. The marketplace 8510 may form part ofthe engines component 128 (FIG. 1) and/or computing resources 150 (FIG.1), or the marketplace 8510 may be a stand-alone system thatcommunicates with the platform 104 via one or more applicationprogramming interfaces (APIs). The marketplace 8510 may serve as arepository/library which users can browse and/or search for enginessuited to a particular need/scenario. Engines 8512 may be selected basedon different criteria including, cost, run time, complexity of model,outputs of model, etc. As explained in greater detail herein, selectedengines 8512 may be incorporated into the platform 104, e.g., via theengine component 128, for subsequent use in clinical trial designsimulations, as described herein. For example, in embodiments, thesimulation facility 110 (FIG. 1) may use two or more different engines8512 from the marketplace 8510.

Entities, e.g., third party and/or in-house developers, may createsimulation engines 8512 for use with different design types, designcomplexity, and/or the like. The created engines 8512 may then beuploaded into the marketplace 8510 via a web interface, an applicationprogramming interface, a File Transfer Protocol (FTP) interface or othersuitable technology for transferring data and/or software files. Themarketplace 8510 may include one or more filters which a user can use tolimit and/or control which engines 8512 are displayed based on one ormore properties. For example, a user may only want to view engines areconfigured for a particular clinical trial type (engines 8514, 8516, and8518) and/or may only want to view engines that have been authored by atrusted developer (engines 8520, 8522, 8524). For example, trial type X,e.g., a cluster randomized design, may require a different type ofengine than trial type Y, e.g., an adaptive randomization design.

Turning to FIG. 86, a non-limiting example of a simulation engine 8610is shown. In embodiments, the simulation engine 8610 may include aheader section 8612 and a main body 8614. The main body 8614 may includeone or more modules for performing a clinical trial simulation, oraspects thereof. The header section 8612 may include one or moredefinitions 8616 that identify the various inputs used by one or moremodules of the main body 8614. One or more of the definitions 8616 maydefine an expected output of the engine 8610. One or more definitions8616 may define the developer of the engine 8610 and/or a version numberof the engine 8610.

Upon being selected, the header section 8612 may be registered with anengine registry of the platform 104, e.g., the engine component 128.Registration of an engine 8610 may include the registry interrogatingthe header section 8612 to determine one or more required inputs and/orexpected outputs of the engine 8610. Registration of an engine 8610 maymake the engine 8610 available as a selectable option in one or more ofthe interfaces of the platform 104, such as in the advisors 114.Registration of the engine 8610 may also include the registrydetermining one or more values for the inputs to the engine 8610 basedon known settings and/or values for various components of the platform104. For example, an input of an engine 8610 specifying how many trialdesigns can be simulated concurrently by the engine 8610 may be set to aparticular value based on known available memory and/or processingresources the platform 104 can make available to the engine 8610.

Turning to FIG. 87, the header section 8612, to include the definitions8616, may be used by one or more of the interfaces of the platform 104,as described herein and represented generally by 8710, to populate oneor more fields 8712. The fields 8712 may include dialogue boxes, textfields, input fields, and/or other suitable widgets for conveying one ormore of: current values/settings for inputs to the engine 8610;requested values/setting for inputs to the engine 8610; recommendedvalue/settings for inputs to the engine 8610; and/or other informationregarding the engine 8610.

In embodiments, inputs to the engine 8610 defined by the user may besaved for later use, which may include system audits and/or replicationof past outputs. For example, a simulation may track the version numberand/or inputs of each engine used in the simulation such that thesimulation may be reproduced. Versions of each engine and inputsassociated with each engine (such as a seed value) may be recorded,stored and/or associated with each trial design, including for purposesof audit or replication.

Moving to FIG. 88, a method 8800 for using a simulation enginemarketplace is shown. The method 8800 includes identifying, in themarketplace, a simulation engine for simulating a clinical trial design8810. The method 8800 further includes importing specifications, e.g.,definitions 8616 (FIG. 86), of the simulation engine 8812, andpopulating a user interface based on the specification 8814.

FIG. 89 depicts another method 8900 for using a simulation enginemarketplace. The method 8900 includes selecting a simulation engine froma marketplace 8910, the simulation engine for simulating a clinicaltrial design. The method 8900 further includes determining inputs to thesimulation engine 8912 and executing a simulation of the clinical trialdesign using the simulation engine with the inputs 8914. The method 8900may include saving the inputs 8916.

FIG. 90 depicts an apparatus 9000 for using a simulation enginemarketplace. The apparatus 9000 includes a user input processing circuit9010 structured to interpret user input data 9012. The apparatus 9000includes a simulation selection circuit 9014 structured to determine asimulation engine 8512 based at least in part on the user input data9012. The apparatus 9000 further includes an engine input selectioncircuit 9018 structured to determine inputs 9020 to the simulationengine 8512 based at least in part on the user input data 9012. Theapparatus 9000 further includes an evaluation circuit 9022 structured toexecute/conduct a simulation using the determined simulation engine 8512and determined inputs 9020. In embodiments, the apparatus 9000 mayfurther include a recording circuit 9024 structured to save thedetermined inputs 9020 and the determined simulation engine 8512 to amemory device, e.g., data component 138 (FIG. 1).

Embodiments of the current disclosure may provide for one or moremethods and apparatuses for evaluating seemingly disparate simulationengines so that a user can determine the most effective and/or efficientengine(s) to use for a particular simulation. As described herein,simulations may use different design models 126 (FIG. 1) and/orsimulation engines 128 (FIG. 1). In embodiments, the simulation facility110 (FIG. 1) may use various engines to simulate different design types,including different design types within one overall clinical trialdesign simulation. Non-limiting examples of differences in enginesand/or engine types include: different underlying purposes, e.g., convexhull analysis vs. simulated annealing, etc.; different creators, e.g.,in-house development teams, vendors, suppliers, etc.; versioning, e.g.,an update to an existing engine of “version 1.0” to “version 1.5”, etc.;and/or other variations.

As will be understood, different engines may not be uniform in how theyevaluate performance criteria. For example, engines created by differententities may make different assumptions and/or use different logic flowsto determine performance criteria for a given simulation. Evaluation ofsimulated designs often requires that the determined performance of anengine can be correctly and/or practically compared against thedetermined performance of other engines. As such, embodiments of thecurrent disclosure provide for benchmarking of engines so that theiroutputs can be normalized to reduce and/or eliminate variations and/orscale the outputs. Reducing variations between engines, in turn,provides for engines to be accurately compared against one another. Inembodiments, benchmarking may include simulating one or more designsusing various engines. Benchmarking may also include varying one or moreparameters common across several different engines/design models andmonitoring for corresponding variations/changes in performance criteria,e.g., engine outputs. Based on the changes, a normalizing factor for oneor more engines may be determined. Benchmarking may also includeproviding a set of inputs with a corresponding set of expected outputs,feeding the inputs to one or more engines to generate actual outputs,and comparing the actual outputs to the expected outputs.

Accordingly, referring now to FIG. 91, a block diagram of a process 9100for benchmarking and/or normalizing simulation engines, in accordancewith an embodiment of the current disclosure, is shown. The process 9100may provide a plurality of inputs 9110 and 9112 to a plurality ofclinical trial design simulation engines 9114 and 9116. The clinicaltrial design engines 9114 and 9116 may then generate first outputs 9118and 9120 based on the inputs 9110 and 9112. Variations 9122 and 9124 ofthe inputs 9110 and 9112, respectively, may be generated and provided tothe engines 9114 and 9116 so that second outputs 9126 and 9128 aregenerated. In embodiments, the variations 9122 and/or 9124 may includesingle item changes, e.g., a single parameter value, from theircorresponding inputs 4510 and/or 9112. In embodiments, the variations9122 and 9124 may be structured to test specific functions of theengines 9114 and 9116. For example, the only difference betweenvariation 9122 and input 9110 may be a value for an expect cost of aclinical trial design. Non-limiting examples of variations may alsoinclude difference in number of expected recruited patients, expecteddrug costs, expected administrative costs, site availability, drugavailability, duration of the trial, and/or any other type ofperformance criteria and/or parameter for simulating a clinical trialdesign.

The set of outputs 9118, 9120, 9126 and/or 9128 may then be evaluated todetermine one or more normalization factors 9130. In embodiments, thenormalization factors 9130 may be based on delta values 9132 and 9134generated by comparing one or more of the outputs to each other. Forexample, in embodiments, the outputs 9118 and 9126 of an engine 9114 maybe compared to generate delta value 9132, wherein the delta value 9132may represent effects that varying the input 9110 had on engine 9114. Inembodiments, output 9118 could be compared to outputs 9126, 9120, and9128 to determine delta value 9134, wherein the delta value 9134 mayreflect differences between how engines 9114 and 9116 handles varianceto the inputs 9110 and 9112.

In embodiments, the normalization factors 9130 may provide for a commonmetric by which to measure the performance of one or more of theplurality of engines 9114 and 9116 against each other. In certainaspects, the normalization factors 9130 may be multiplied against one ormore of the outputs 9118, 9120, 9126, and/or 9128. In embodiments, thenormalization factors 9130 may differ with respect to differencesbetween the inputs 9110 and 9112 and their corresponding variations 9122and 9124.

In embodiments, a first clinical trial design simulation engine 9114 ofthe plurality may be structured to simulate a first clinical trialdesign that is of a different type than a second clinical trial designwhich a second clinical trial design simulation engine 9116 of theplurality is structured to simulate. For example, engine 9114 may bestructured to simulate trial designs comparing two different drugs toeach other, while engine 9116 may be structured to simulate trialdesigns for evaluating non-drug related therapies. In embodiments, afirst clinical trial design simulation engine 9114 of the plurality maybe of a different version of a second clinical trial design simulationengine 9116 of the plurality. For example, engine 9116 may be an updatedversion of the engine 9114, wherein 9116 may utilize different logicand/or other programmatic changes. In embodiments, a first clinicaltrial design simulation engine 9114 of the plurality may have beengenerated by a first entity and a second clinical trial designsimulation engine 9116 of the plurality may have been generated by asecond entity of the plurality distinct from the first entity. Forexample, engine 9114 may be structured to simulate the same type ofclinical trial designs for which engine 9116 is structured to simulate,but engine 9114 may have been built by an in-house development teamwhile engine 9116 may have been built by a user of the platform,third-party contractor or separate company. In embodiments, the outputs9118, 9120, 9126, and/or 9128 may include metadata. Non-limitingexamples of metadata may include version number of the engine used,authorship of the engine used, creation/simulation date of the output,and/or other types of properties.

In embodiments, the delta values 9132 and/or 9134 may represent outputvariability between one or more of the engines 9114 and 9116 for similarinputs, e.g., input 9110, or between the same engine 9114 across aninput 9110 and the corresponding variation 9122. In embodiments, thedelta values 9132 and 9134 and/or the normalization factors 9130 may beused, in part, to determine valid ranges for the output values of anengine 9114 and 9116. The valid ranges, in turn, may be used todetermine whether an engine is providing faulty information, e.g., theengine may have incorrect logic and/or coding errors.

Illustrated in FIG. 92 is a method 9200 for benchmarking and/ornormalizing clinical trial design simulation engines. The method 9200includes providing inputs to a plurality of clinical trial designsimulation engines 9210. The method 9200 includes receiving firstoutputs of the plurality of clinical trial design simulation engines inresponse to the inputs 9212. The method 9200 includes providingvariations of the inputs to the plurality of clinical trial designsimulation engines 9214. The method 9200 further includes receivingsecond outputs of the plurality of clinical trial design simulationengines in response to the variations 9216. The method 9200 includesevaluating the first and the second outputs to determine delta values9218. The method 9200 includes determining, based in part on the deltavalues, a plurality of normalization factors for the plurality ofclinical trial design simulation engines 9220.

In embodiments, engine variability may be confined to small number ofparameters or values. For example, variations in engine versions (suchas from one version to another) may be confined to minor algorithmchanges related to corner cases, extreme values or the like. In somecases, various versions of engines may perform exactly the same exceptfor a small range of values at extreme ends or specific values. Enginesmay be evaluated for exact ranges of inputs and/or outputs for whichengines are comparable, ranges of inputs and/or outputs for whichengines differences exhibit acceptable error, and range of inputs and/oroutputs for which engines are not comparable. Configuration data may beused to indicate for which values and/or ranges of values engines arecomparable. Data that is in the comparable range may be marked ascomparable. Data in other ranges may be flagged as not comparable ormarked with an estimated error for user review. In some cases, a usermay specify threshold for acceptable error values.

Referring to FIG. 93, an apparatus 9300 for benchmarking and/ornormalizing clinical trial design simulation engines is shown. Theapparatus 9300 includes an output processing circuit 9310 structured tointerpret output data 9312 from a plurality of clinical trial designsimulation engines, e.g., 9114 and 9116 (FIG. 91). Output data 9312 maycorrespond to one or more of output data 9118, 9120, 9126, and/or 9128(FIG. 91). The apparatus 9300 includes a comparison circuit 9314structured to compare the interpreted output data 9312 to expectedoutput data 9316. Expected output data 9316 may include previouslycalculated outputs for the engines 9114 and/or 9116 and/or outputs,calculated using engines outside of the plurality of engines 9114 and9116, for the inputs 4510 and/or 9112 (FIG. 91), e.g., an agreed uponbenchmark standard. The apparatus 9300 includes a normalization circuit9318 structured to determine a plurality of normalization factors 9130for the plurality of clinical trial design simulation engines 9114 and9116. The apparatus 9300 further includes a normalization provisioningcircuit 9322 structured to transmit the plurality of normalizationfactors 9130.

Referring now to FIG. 94, in addition to optimizing a design for asingle clinical trial, embodiments of the platform 104 (FIG. 1) mayprovide for optimization of clinical trial designs across aplurality/set of clinical trials 9410 and/or aspects of the clinicaltrials. As will be appreciated, optimization over a set of relatedclinical trials may result in better overall performance for the set, ascompared to optimizing each element, aspect, or clinical trial in theset individually and combining the results. For example, two clinicaltrial designs A and B may impact each other such that conductingclinical trials A and B concurrently is more efficient, with respect toa given performance criteria, than conducting A and B at differenttimes. As another example, conducting clinical trials A and B, whethersuccessively or concurrently, may be more efficient, with respect to agiven performance criteria, than conducting one of clinical trial A orclinical trial B without conducting the other.

Improving the performance of a set may, in turn, improve theeffectiveness and/or cost efficiencies of the related clinical trials.

As shown in FIG. 94, two or more of the clinical trials, e.g., clinicaltrial A 9412, clinical trial B 9414, and/or clinical trial C 9416 may berelated to each other through one or more associations 9418.Non-limiting examples of associations 9418 include: trial sites 9420; anorder of execution and/or dependencies 9422; shared resources 9424;clinical trial phases 9426; test subjects 9428, and/or other aspects ofdesign space, scenario space and performance space. Trial sites 9420 mayinclude any facility that participates in and/or performs a servicerelated to execution of a clinical trial and/or any other type offacility, as described herein, with respect to the term “site” and/or“clinical trial site”. An order of execution 9422 and/or dependency mayinclude the sequencing of the conduction/execution of one or moreclinical trials. For example, clinical trial A 9412 may execute beforeclinical trial B 9414 which may execute before clinical trial C 9416. Anorder of execution 9422 may also specify that two more clinical trialsexecute concurrently, e.g., have overlapping time periods. For example,clinical trial A 9412 may execute concurrently, e.g., at the same time,as clinical trial B 9414. Non-limiting examples of shared resources 9424may include administrative personnel, medical practitioners, and/or drugavailability/supply. Clinical trial phases 9426 may include phases 0-4,which may be performed sequentially. In embodiments, the platform 104may simulate all, or a large percentage, of the feasible clinical trialdesigns/variations for each of clinical trials (and correspondingphases) and determine the optimal or near optimal combination of trialvariations for each phase. Test subjects 9428 may include a drug and/ortreatment that is the subject/purpose of a clinical trial 9410. Inembodiments, the set of clinical trials 9410 may include trials that areperformed in parallel but are related to different aspects of the samedrug/treatment or related drugs/treatments.

In embodiments, a specification 9430, e.g., a data file (to include oneor more records in a relational and/or object database) and/or writtendocument, may record and/or define the one or more associations 9418.The specification 9430 may be stored in one or more databases within thedata facility 138 (FIG. 1) where it may be retrieved from and/or updatedas needed.

As will be explained in greater detail below, one or more clinical trialdesigns 9432, 9434, 9436, 9440, 9442, 9444, 9448, 9450 and 9452(collectively referred to as 9456) may be generated for each of theclinical trials 9410 based at least in part on the specification 9430and/or associations 7118. For example, three (3) clinical trial designs9432, 9434, and 9436 (collectively referred to herein as 9438) may begenerated for clinical trial A 9412, three (3) clinical trial designs9440, 9442, and 9444 (collectively referred to herein as 9446) may begenerated for clinical trial B 9414, and three (3) clinical trialdesigns 9448, 9450, and 9452 (collectively referred to herein as 9454)may be generated for clinical trial C 9416. While the foregoing exampleincludes three (3) clinical trials each having three (3) correspondingclinical trial designs, it will be understood that any number of two ormore (>2) clinical trials 9410 may be used with any number ofcorresponding clinical trial designs 9456.

Turning to FIG. 95, a permutation set 9510 may be determined from theclinical trial designs 9456 (FIG. 94). The permutation set 9510 may be acollection of the possible combinations of the clinical trial designs9456. In embodiments, each item in the permutation set 9510 may includeat least one clinical trial design from each of the subgroups 9438,9446, and/or 9454 corresponding to the clinical trials 9412, 9414, and9416. In the case of three (3) clinical trials, as shown in FIG. 94,each of the combinations in the permutation set 9510 may associate aclinical trial design from group 9438 (derived from clinical trial A9412) with two other clinical trial designs, one from group 9446(derived from clinical trial B 9414) and one from group 9454 (derivedfrom clinical trial C 9416). For example, as shown in FIG. 95, a firstitem 9512 of the permutation set 9510 may include design A1 9432, designB1 9440, and design C1 9448. A second item 9414 of the permutation set9510 may include design A1 9432, design B1 9440, and design C2 9450. Athird item 9516 of the permutation set 9510 may include design A1 9432,design B1 9440, and design C3 9452. A fourth item 9518 of thepermutation set 9510 may include design A1 9432, design B2 9442, anddesign C1 9448. As will be understood, the permutations may continue sothat the set 9510 contains all possible permutations/combinations asrepresented by the final item 9020. In embodiments, the permutation set9510 may include only a subset of the possiblepermutations/combinations. In embodiments, the permutation set 9510 mayinclude variations of a permutation/combination based on the one or moreassociations 9418 (FIG. 94). For example, where the order of theclinical trials in item 9512 from left to right represents the executionorder of the clinical trials, the permutation set 9410 could includevariations of item 9412, e.g., clinical trial design C1 9448, clinicaltrial design B1 9440, and clinical trial design A1 9432, representing acase where trial C1 9448 executes before trial B1 9440 which executesbefore trial A1 9432.

Combined performance criteria 9526 may be generated for each item of thepermutation set 9510 where the combined performance criteria representsthe collective performance criteria of the clinical trials within theitem. For example, as shown in FIG. 95, combined performance criteria9522 may be generated for item 9512, combined performance criteria 9523may be generated for item 9514 and so on until all items have acorresponding combined performance criteria, as represented by combinedperformance criteria 9524 and corresponding item 9520. In embodiments,the platform 104 may simulate all, or a large percentage, of thefeasible trial options for each of the parallel trials to determine theoptimal or near optimal combination of trial variations. In some cases,optimization of clinical trials, as disclosed herein, may also includeother aspects of trials such as patient recruitment and clinical trialresources (including drug supply). Simulations of trials may includedeterminations of requirements for drug supply and other aspects.

Analysis of the combined performance criteria 9526 may provide fordetermination of which set/permutation/combination of designs is theoptimal combination to use for the set of clinical trials 9410.

Accordingly, turning to FIG. 96, a method 9600 for optimization ofclinical trial designs across a plurality/set of clinical trials 9410(FIG. 94) and/or aspects of the clinical trials is shown. The method9600 includes obtaining a specification 9610. The specification 9430(FIG. 94) may define one or more associations 9418 (FIG. 94) between twoor more clinical trials 9410. The method 9600 further includesdetermining clinical trial designs for each of the two or more clinicaltrials 9612. In embodiments, the clinical trial designs may be based atleast in part on the specification 9430 and/or the associations 9418.The method 9600 further includes generating a permutation set of theclinical trial designs 9614. The method 9600 further includesdetermining combined performance criteria for each item of thepermutation set 9616. The method 9600 may further include recommendingone or more items of the permutation set 9618. The recommendation may bebased at least in part on the combined performance criteria 9526 (FIG.95).

Moving to FIG. 97, in embodiments, the method 9600 may include applyinga first filter to the permutation set 9710. In embodiments, the firstfilter may be based at least in part on a Pareto analysis, as describedherein. For example, a combination Pareto set may be generated byapplying a Pareto analysis to the permutation set 9510, wherein thecombination Pareto set is a subset of the permutation set 9510. In suchembodiments, the recommended items from the permutation set may bemembers of the combination Pareto set.

In embodiments, the method 9600 may include applying a second filter tothe permutation set 9712 and/or the combination Pareto set. Inembodiments, the second filter may be based at least in part on a convexhull analysis, as described herein. In such embodiments, the secondfilter may be applied to the combination Pareto set wherein therecommended items of the permutation set are on a convex hull of thecombination Pareto set.

Illustrated in FIG. 98 is an apparatus 9800 for implementing the method9600. The apparatus 9800 includes a specification receiving circuit 9810to obtain and/or interpret specification data 9812 corresponding to aspecification 9430 (FIG. 94). In embodiments, the specification may bebased at least in part on a globally optimum clinical trial designdetermined in accordance with the systems and methods described herein.The apparatus 9800 further includes a variation determining circuit 9814structured to determine clinical trial designs 9456. Determination ofthe clinical trial designs 9456 may be based at least in part on thespecification data 9812. The apparatus 9800 further includes apermutation circuit 9816 structured to generate a permutation set 9510of combinations of the clinical trial designs 9456. The apparatus 9800further includes an evaluation circuit 9818 structured to determinecombined performance criteria 9526 for each item of the permutation set9510. The apparatus 9800 may further include a recommendation circuit9820 structured to recommend one or more of the permutation set, e.g.,select a recommended permutation 9830. The recommendation 9830 may bebased at least in part on the combined performance criteria 9526.

In embodiments, the apparatus 9800 may include a first filtering circuit9822 structured to filter the permutation set 9510. The first filter9822 may be based at least in part on a Pareto analysis and generate acombination Pareto set 9824, as discussed herein. In such embodiments,the recommendation circuit 9820 may be further structured to select therecommendation 9830 from the combination Pareto set 9824.

In embodiments, the apparatus 9800 may include a second filteringcircuit 9826. The second filtering circuit 9826 may be based at least inpart on a convex hull analysis. In embodiments, the second filteringcircuit may filter the combination Pareto set 9824. In such embodiments,the recommendation circuit 9820 may be further structured to select therecommendation 9830 from the set of points within the combination Paretoset that fall on the convex hull 9828. Embodiments of the apparatus 9800may include additional circuits that may perform other types ofanalysis, e.g., simulated annealing, Monte Carlo, and/or the like.

As will be appreciated, by generating permutations based on associations7118, as described herein, embodiments of the disclosure may determineoptimized combinations and/or execution orderings for two or moreclinical trials. For example, it may be the case that clinical trial Aand clinical trial C can execute at the same facility at the same timewith the same administrative staff, while clinical trial B needs toexecute after clinical trial C due to dependencies. Embodiments of thecurrent disclosure may also determine whether certain portions/subpartsof two or more clinical trials should be executed together (either intime and/or location) or separately (either in time and/or location). Inother words, some embodiments of the current disclosure may provide foran overall ordering and/or sequencing of multiple clinical trials, toinclude ordering of portions/subparts of the clinical trials. Further,filtering the permutation set, as described herein, may reduce thenumber of non-optimal combinations that need to be considered, thusreducing the amount of time to determine the optimal combination.

In embodiments, the platform's 104 (FIG. 1) infrastructure, e.g.,components 106, 108, 110, 112, 138, and/or 150, includes engines 128,models 126 and/or the underlying algorithms, and may be used to optimizeclinical designs for robustness against variations in prior probabilityassessments. In other words, instead of determining optimal clinicaltrial designs for a given set of scenarios and/or design parameters,some embodiments of the current disclosure may provide for determiningrobustness for a particular clinical trial design.

As such, embodiments of the platform 104 may operate in a forward modeof operation and/or an inverse mode of operation. In “forward” operationmode, the platform 104 may be used to provide design recommendations forfixed scenario probabilities over a user selected range of criteriaweights, as disclosed herein. In “inverse” operation mode (also referredto herein as “backwards” operation mode), however, the platform 104 maybe used to assess the impact of departures from the assumedprobabilities of the scenarios (e.g., a departure modeled by multinomialdistribution with n=1). In embodiments, the inverse operation mode maybe used to compute design performance on multiple criteria for a vectorof criteria weights, which may be fixed, while varying multinomialprobability vectors. This may be done using algorithms for the forwardoperation mode by interchanging the role of the multinomialprobabilities and the weights. As will be appreciated, thisinterchanging of roles is possible, in part, due to the mathematicalmodels of the forward and backward modes of operation being duals ofeach other, in the sense that fixing either the weights or the scenarioprobabilities typically leads to the same linear model structure for thedesign performance value.

A measure of the robustness, also referred to herein as a “robustnessvalue”, of a clinical trial design may correspond to a size of the rangeof scenario probabilities for which the design is optimal. Inembodiments, this range is convex, thus providing for the application ofPareto analysis/optimality, convex hull analysis, and/or simulatedannealing. In embodiments, the dimension of the vector of themultinomial distribution for scenarios may be reduced by exploitinguniformity of probabilities over subsets of scenarios (e.g., using three(3) or five (5) ordered categories of likelihood) and/or functionalrelations between scenario probabilities. This may result in reductionsin the number of multinomial vectors and speeds up computations.

In embodiments, if a user, e.g., 102 (FIG. 1) provides a prior (e.g., aDirichlet distribution) over the multinomial probability vector forscenarios the inverse mode of operation computes the posteriordistribution for the weighted criterion vector to provide summarymeasures of robustness such as one or more of the posterior means,standard deviation, and/or credible intervals. As will be appreciated,in embodiments, the forward and inverse modes of operation can bereversed in sequence if there is certainty around weights for criteriaand optimal robustness to scenario assumptions is of concern.

Accordingly, illustrated in FIG. 99, a method 9900 for determiningrobustness of a clinical trial design. The method 9900 may provide foroperation of the platform 104 in an “inverse” mode of operation, asdescribed herein. As such, the method 9900 includes obtaining a clinicaltrial design 9910. In embodiments, the clinical trial design may havebeen generated in accordance with the “forward” mode of operation of theplatform 104, as described herein. The method 9900 further includesdetermining a space of scenario probability variations for the clinicaltrial design 9912, and evaluating the space of scenario probabilityvariations to determine a robustness of the clinical trial design 9914.

Turning to FIG. 100, another method 10000 for determining robustness ofa clinical trial design is shown. The method 10000 may provide foroperation of the platform 104 in an “inverse” mode of operation, asdescribed herein. As such, the method 10000 includes obtaining aclinical trial design 10010. In embodiments, the clinical trial designmay have been generated in accordance with the “forward” mode ofoperation of the platform 104, as described herein. The method 10000 mayinclude weighting one or more design criteria for the clinical trialdesign 10012. The method 10000 may include reducing a dimensionality ofthe space of scenario probability variations 10018 by evaluatingrelations between two or more scenarios within the space 10020. Themethod 10000 further includes determining a space of scenarioprobability variations for the clinical trial design 10014. Inembodiments, determining the space of scenario probability variations10014 is based at least in part on the one or more weighted designcriteria. In embodiments, the weights of the design criteria may befixed. The method further includes evaluating the space of scenarioprobability variations to determine a robustness of the clinical trialdesign 10016. In embodiments, evaluating the space of scenarioprobabilities 10016 includes conducting a Pareto analysis 10022 and/or aconvex hull analysis 10024.

Illustrated in FIG. 101 is an apparatus 10100 for determining robustnessof a clinical trial design is shown. The apparatus 10100 may form partof the platform 104 and provide for operation of the platform 104 in an“inverse” mode of operation, as described herein. As such, the apparatus10100 includes a specification processing circuit 10110 structured tointerpret clinical trial design data 10112 corresponding to a clinicaltrial design. In embodiments, the clinical trial design data may havebeen generated in accordance with the “forward” mode of operation of theplatform 104, as described herein. The apparatus 10100 further includesa space determining circuit 10114 structured to determine, based atleast in part on the clinical trial design data 10112, a space ofscenario probability variations 10116 for the clinical trial design. Theapparatus 10100 further includes an evaluation circuit 10118 structuredto determine, based at least in part on the space of scenarioprobability variations 10116, a robustness value 10120 of the clinicaltrial design. The apparatus 10100 further includes a robustnessprovisioning 10122 circuit structured to transmit the robustness value10120.

In embodiments, the forward and inverse modes of operations can beexecuted sequentially over a plurality of iterations. In some examples,designs may be evaluated in the forward mode of operation to evaluatedesigns. Designs may be evaluated for different performance parameterweights to determine one or more designs of interest for the weights.The designs of interest for the determined weights may be furtherevaluated to determine the robustness of the designs for scenario. Foreach design, the platform may be operated in reverse mode for eachdesign of interest to determine the robustness of each design. In somecases, the robustness results may reveal that the design of interest hasunsatisfactory robustness. In response to unsatisfactory robustness theplatform may be operated in forward mode to find new designs ofinterest. In some cases, the operation of platform in the forward modemay be modified based on the robustness results. Modifications mayinclude changing weighting of performance criteria, changing designcriteria, changing scenario criteria, and the like. Forward mode ofoperation may be used to find new designs of interest and the platformmay be again operated in reverse mode to identify robustness of the newdesigns of interest. The cycles of forward and reverse operation may berepeated until design with acceptable robustness and performance arefound.

Referring to FIG. 102, a method 10200 for updating a clinical trial isshown. Since recommendation of globally optimal designs, as disclosedherein, are generally predictive, it is possible that one or moreparameters used to determine a globally optimum design for a clinicaltrial may deviate from what actually occurs during conduction/executionof the trial, i.e., while the trial is underway. For example, a globallyoptimum design may have been determined based on a scenario where nomajor worldwide health emergencies occur during the duration of theclinical trial, when, in actuality, a global pandemic emerges shortlyafter the start of a clinical trial based on the globally optimumdesign. In such a case, the original globally optimum design may nolonger be the optimum design. Updating of a clinical trial, as describedherein, may occur multiple times through the course/duration of theclinical trial. In some embodiments, updating of the clinical trial, asdescribed herein, may be performed on a continuous basis throughout theduration of the clinical trial.

Accordingly, the method 10200 includes obtaining a first simulationoutput for a first set of clinical trial designs for the clinical trial10210. The first simulation output includes first performanceparameters, as disclosed herein, associated with each design in thefirst set of clinical trial designs for a first set of criteria. Themethod 10200 further includes determining, from the first set ofcriteria, a first optimality criteria for evaluating the first set ofclinical trial designs 10212. The method 10200 further includesdetermining, within the first set of clinical trial designs, a firstglobally optimum design based at least in part on the first optimalitycriteria and the first performance parameters 10214. The clinical trialmay then be configured based at least in part on the first globallyoptimum design, e.g., the clinical trial may be made to conform to theglobally optimum design.

As further shown in FIG. 102, the method 10200 may includeconducting/executing the clinical trial based at least in part on thefirst globally optimum design 10216. Conduction of the clinical trialmay be defined by a start/beginning 10218 of the clinical trial and astop/end 10220 of the clinical trial. In embodiments, the start 10218may be the occurrence of the first patient recruitment. In embodiments,the start 10218 may be the occurrence of the first interaction betweenadministrative personnel (for the clinical trial) and a patient orrecruitment site, in respect of the trial. In embodiments, the start10218 may be the first occurrence of a patient receiving a treatment(including receiving a drug). In embodiments, the stop 10220 may be thelast occurrence of patient receiving a treatment (including receiving adrug). In embodiments, the stop 10220 may be the occurrence of the lastinteraction between administrative personnel (for the clinical trial)and a patient or recruitment site, in respect of the trial. The timebetween the start 10218 and the stop 10220 may constitute the durationof the clinical trial as that term is user herein. In embodiments,conduction of the clinical trial may include commencement of any portionand/or process of the clinical trial whether performed in successionand/or intermittently.

After the start 10218 of the clinical trial, but before the stop 10220,the globally optimum design may be reassessed. As such, the method 10200includes obtaining, during conduction of the clinical trial, a secondsimulation output for a second set of clinical trial designs for theclinical trial 10222. The second simulation output includes secondperformance parameters associated with each design in the second set ofclinical trial designs for a second set of criteria. In embodiments, thesecond simulation output may be different than the first simulationoutput. For example, the second simulation output may be from anotherevaluation of the clinical trial designs. In embodiments, the secondsimulation output may be the same as the first simulation output. Forexample, the first simulation output may be reused. In embodiments, thesecond performance parameters may be different than the firstperformance parameters. For example, the second performance parametersmay include more or fewer parameters than the first performanceparameters. In embodiments, the second performance parameters may be thesame as the first performance parameters. In embodiments, the second setof designs may be the same or different than the first set of designs.For example, the second set of designs may include additional designsand/or have removed designs as compared to the first set of designs. Inembodiments, the second set of criteria may be the same or differentthan the first set of criteria. For example, constraints on the clinicaltrial may have changed since the start 10218.

The method 10200 further includes determining, from the second set ofcriteria, a second optimality criteria for evaluating the second set ofclinical trial designs 10224. In embodiments, the second optimallycriteria may be the same or different from the first optimally criteria.For example, a user may have previously determined the globally optimumdesign with respect to shortest duration and wish to do so again for thesecond globally optimum design. As another example, a user may havepreviously determined the globally optimum design with respect toshortest duration and may now wish to determine the globally optimumdesign with respect to costs.

The method 10200 further includes determining, within the second set ofclinical trial designs, a second globally optimum design 10226.Determination of the second globally optimum design may be based atleast in part on the second optimality criteria and the secondperformance parameters. The method 10200 may further include adjustingthe clinical trial based at least in part on the second globally optimumdesign 10228. Adjustment of the clinical trial may include conformingthe clinical trial to the second globally optimum design.

Illustrated in FIG. 103 is another method 10300 for updating a clinicaltrial. In particular, method 10300 identifies a globally optimum designfor a clinical trial after the start 10312 of the clinical trial, butbefore the end 10314 of the clinical trial, where an initial globallyoptimum design may not have been determined, or was not determined by anentity performing method 10300. Accordingly, the method 10300 includesobtaining, during conduction of the clinical trial 10316, a simulationoutput for a set of clinical trial designs for the clinical trial 10218.The simulation output includes performance parameters associated witheach design in the set of clinical trial designs for a set of criteria.The method 10300 further includes determining, from the set of criteria,an optimality criteria for evaluating the first set of clinical trialdesigns 10320. The method 10300 further includes determining, within theset of clinical trial designs, a globally optimum design based at leastin part on the optimality criteria and the performance parameters 10322.The method 10300 may further include recommending the globally optimumdesign 10324. Recommendation may include transmitting the globallyoptimum design to an entity performing the clinical trial. Therecommended globally optimum design may be the first time a globallyoptimum design was calculated/determined for the clinical trial, or theglobally optimum design may be an update to a previouslycalculated/determined globally optimum design. In embodiments, themethod 10300 may not include recommending the globally optimum design,but rather may include adjusting the clinical trial based at least inpart on the globally optimum design 10326. It is to be understood,however, that embodiments of the method 10300 may not include adjustingthe clinical trial based at least in part on the globally optimumdesign. In embodiments, the method 10300 may include both recommendingand adjusting the clinical trial based at least in part on the globallyoptimum design.

In addition to the design of a clinical trial, the success of theclinical trial often depends on the ability to recruit a satisfactorynumber of patients, also referred to herein as “subjects”, suitable toparticipate in the clinical trial. The number of suitable patientsavailable to be recruited for a clinical trial is, in turn, typically afunction of the sites selected for the clinical trial, also referred toherein as a “site selection”.

In some cases, a wrong choice in the selection of sites for a clinicaltrial may reduce the usefulness of the trial even if the trial isexecuted without error. In some cases, a wrong choice in the selectionof sites for a clinical trial may inhibit and/or prevent completion ofthe clinical trial, e.g., not enough suitable patients are recruited tosatisfy applicable guidelines and/or industry requirements. In somecases, different choices in site selection for a clinical trial mayresult in very different costs, completion times, and/or otherperformance parameters for the clinical trial.

The selection of sites for a clinical trial may include considerationsand tradeoffs between hundreds or even thousands of site selections,also referred to herein as site selection options, e.g., differentgroupings/sets of selected sites. For example, different site selectionoptions, often have different values for performance criteria, e.g., thetype of clinical trial being conducted, the minimum and/or maximumnumber of suitable patients available to be recruited, the time requiredto complete the clinical trial, the costs associated with conducting theclinical trial, and/or the like. Traditionally, site selection forclinical trials has been based on heuristics and experiencedprofessionals to determine a set of parameters likely to result in asite selection that produces a successful clinical trial. However,traditional approaches are not capable of evaluating more than a handfulof site selection options and corresponding tradeoffs. As a result,traditional approaches to site selection often miss site selectionoptions that may result in better performance. As the cost of a clinicaltrial may exceed tens of millions or even hundreds of millions ofdollars and/or may take years to complete, small differences in theperformance between site selections for a clinical trial may result inlarge impacts on the overall cost and/or time associated with theclinical trial.

The complexity of site selection often requires aspects of statisticalexpertise, clinical design expertise, and software expertise, which maynot be available in many organizations. As such, many organizationsfallback on the use of generic site selection methodologies due to theirinability to find optimal or near-optimal site selections for aparticular clinical trial.

Accordingly, embodiments of the current disclosure may provide for asite selection platform, systems, and methods for evaluation and/orcomparison of site selection options for a clinical trial. Inembodiments, evaluation and/or comparison may include a large number ofsite selection options. In some embodiments, the platform, systems, andmethods described herein may be used to evaluate hundreds, thousands, oreven millions of site selection options for a clinical trial and may beused to find the optimal or near-optimal site selection for a trial.

The site selection platform may be used for site selection. Inembodiments, a site selection platform may support a team, as describedherein, in collaborating and surfacing all the inputs that are key toconsider for preparing and selecting an optimal site selection. The siteselection platform may use cloud and distributed computing so the teamcan simulate hundreds of millions of site selection variants/optionsacross all those inputs. The site selection platform may present theteam with prioritized options and visualizations to enable theinterrogation of the drivers of value.

A site selection platform may enable a team to quickly identify optimalsite selections and the factors that most strongly drive performancefactors, strategic goals, and the like. A site selection platform, asdescribed herein, may leverage emerging technologies to provide optionsfor advanced simulations, distributed computing, visualizations, and thelike. The site selection platform may leverage methodological knowledge,analysis of the business value of different design choices, and/oranalysis of regulatory risk and operational complexity to determineoptimum or near optimum site selections. The site selection platform maydetermine optimum or near optimum site selections by leveraging a novelworkflow, speed and/or computing innovations, and/or powerfulvisualizations for study analysis and optimization.

A site selection platform may improve how data and processes are used tomake better decisions on site selections. Improvements may result fromrecognizing which innovative options might significantly increase goals.Improvements may be obtained by communicating the benefits of specificsite selections in a way that that intuitively allows a variety of teammembers to understand a particular site selection and/or possibleoptions for the site selection of a clinical trial. A site selectionplatform may support a team in collaborating and surfacing all theinputs that are key to consider for preparing and selecting an optimalsite selection. The site selection platform may present the team withprioritized options and insightful visualizations to enableinterrogation of the drivers of value.

FIG. 104 shows an embodiment of a platform/system for evaluation andcomparison of site selections for a clinical trial. The platform 10404may form part of the platform 104 (FIG. 1) or the platform 10404 may bestand-alone from the platform 104. In embodiments, the platform 10404may communicate with the platform 104 via one or more applicationprogramming interfaces (APIs). The platform 10404 may provide for asystem for providing users with facilities and methods for determining,evaluating, and/or comparing site selections. The facilities describedherein may be deployed in part or in whole through a machine thatexecutes computer software, modules, program codes, and/or instructionson one or more processors, as described herein, which may be part of orexternal to the platform 10404. Users may utilize the platform 10404 toidentify site selections for criteria, evaluate the site selections,compare site selections, determine optimal site selections, and thelike.

A user may interact with the platform 10404 through one or more userdevices 10402 (e.g., computer, laptop computer, mobile computing device,and the like). The platform 10404 may be implemented and/or leverage oneor more computing resources 10450 such as a cloud computing service10452, servers 10454, software as a service (SaaS), infrastructure as aservice (IaaS), platform as a service (PaaS), desktop as a Service(DaaS), managed software as a service (MSaaS), mobile backend as aservice (MBaaS), information technology management as a service(ITMaaS), and the like. The platform 10404 may be provided or licensedon a subscription basis and centrally hosted (e.g., accessed by usersusing a client (for example, a thin client) via a web browser or otherapplication, accessed through or by mobile devices, and the like). Inembodiments, elements of the platform 10404 may be implemented tooperate on various platforms and operating systems. In embodiments,interfaces for the user device 10402 through which the users mayinteract with the platform may be served to the user device 10402through a webpage provided by a server of the platform 10404, anapplication, and the like.

The platform 10404 may include one or more facilities such as aconfiguration facility 10406, simulation facility 10410, analysisfacility 10408, interfaces facility 10412, data facility 10438, andcomputation resources 10450.

The configuration facility 10406 may include advisors 10414, which mayinclude one or more wizards, tools, algorithms, recommenders,configuration elements, questioners, and the like. Advisors may be usedto receive data and/or define or develop space definitions 10416.

Space definitions 10416 may include aspects of site selection criteriaspace 10510 (FIG. 105). Site selection criteria space may define values,ranges of values, types, ranges of types, and the like that may definegeneral required characteristics of a site selection, as required by aclinical trial. Non-limiting examples of site selection criteriainclude: maximum and/or minimum duration of the clinical trial, maximumand/or minimum costs of the clinical trial, a minimum and/or maximumnumber of required patients to complete the trial, and/or the like. Inembodiments, site selection criteria space may also include criticaldates (the start, stop, duration, and/or milestones of a clinicaltrial), required protocols, geographic distribution of patients,demographics of patients, and/or the like.

Space definitions 10416 may include aspects of site selection space 2412(FIG. 105). Site selection space 2412 may include the set of parametersand values of the parameters that define different options andvariations of sites for implementation of clinical trials. Non-limitingexamples of site selection space may include expected patientrecruitment, expected patient dropout rate, geographical locations,patient demographics, expected costs, and/or the like. The siteselection space may include all possible permutations of the parameters.For example, one site selection may be configured with differentexpected patient recruitment and different patent dropout rates. Thesite selection space may include all possible permutations of thedifferent expected costs of the clinical trial for all the differentexpected patient dropout rates. The site selection space may include allthe permutations of all the parameters associated with a site selection.The site selection space may include millions of possible site selectionvariations. A site selection platform may evaluate all permutations ofparameters of the site selection space. A site selection platform mayevaluate a partial set of permutations of parameters of the siteselection space. The partial set of permutations may be defined by auser. The partial set of permutations may be automatically defined, suchas according to the site selection criteria parameters.

Space definitions 10416 may include aspects of site selection scenariospace 2414 (FIG. 105). Site selection scenario space may include the setof parameters and values of the parameters that define different optionsand variations of scenarios associated with site selections. Siteselection scenario space may define the parameters of the environmentassociated with one or more sites. Non-limiting examples of siteselection scenario space include: expected weather conditions, expectedpandemics; expected economic conditions; expected resource availability,to include administrative personnel; and/or the like. The site selectionscenario space may include all possible permutations of the parameters.For example, one scenario may be configured with a range of values foraverage patient age and a range of values for average weatherconditions, e.g., how will varying weather conditions affect the abilityof patients of varying age to participate in a clinical trial. The siteselection scenario space may include all the permutations of all theparameters associated with scenarios. The site selection scenario spacemay include millions of possible scenario variations. A site selectionplatform may evaluate all permutations of parameters of the siteselection scenario space. A site selection platform may evaluate apartial set of permutations of parameters of the site selection scenariospace. The partial set of permutations may be defined by a user. Thepartial set of permutations may be automatically or semi-automaticallydefined, such as according to the site selection criteria parameters.

Space definitions 10416 may include aspects of site selectionperformance space 2416 (FIG. 105). Site selection performance space mayinclude the set of parameters and values of the parameters that definethe evaluation criteria for a site selection. Parameters may include:predicted patient recruitment (as estimated by simulation), net presentvalue (NPV), expected NPV, incremental NPV, study cost, incrementalstudy cost, study budget, incremental study budget, time to complete,incremental time to complete, time to market, incremental time tomarket, clinical utility, incremental clinical utility, probability ofregulatory acceptance, incremental probability of regulatory acceptance,probability of success, incremental probability of success, statisticalpower, incremental statistical power, number of patients, incrementalnumber of patients, number of sites, incremental number of sites, studycomplexity, incremental study complexity, operational complexity,incremental operational complexity, dose selected, incremental doseselected, statistical design, incremental statistical design, peakrevenue, revenue at year five (5), other revenue numbers, incrementalrevenue, market introduction, whether market introduction beatscompetition entry, number of treatment arms, hypothesissuperiority/equivalence/non-inferiority, other choices aroundstatistical design, treatment effect, hazard ratio, and other choicesaround estimating the characteristics of the patient population,response, and safety profile, screening criteria, dropout rate, andother choices around modeling/estimating the characteristics andbehaviors of the patient population and other factors that impact howthe study evolves and its likelihood of achieving its goals (howslowly/quickly patients enroll, etc.), site payments and other choicesaround operational aspects of the study that can impact how the studyevolves and its likelihood of achieving its goals, cost per patient,cost per site, or other cost factors, selections made in other projects(across users within customer companies or organizations and across allusers of the platform), priorities set by the customer company ororganization, and/or other user-defined filters based on availableinputs and outputs of the platform or in the systems and methodsdescribed herein. In embodiments, any of the parameters and variablesdescribed herein may be incremental parameters and variables. Siteselections may be evaluated and compared against all of the parametersof the performance space or a subset of the parameters of theperformance space. A set of site selections, e.g., one or more groupseach including one or more possible sites, may be evaluated for one ormore of the performance parameters. The performance parameters and thevalues of the performance parameters of site selection and/or clinicaltrial design define the performance space of the set of site selections.

The configuration facility 10406 may include a combinations component10418. The combinations component 10418 may automatically orsemi-automatically define the design space and/or scenario space thatmay be evaluated by the platform 10404.

The simulation facility 10410 of the platform 10404 may, based on thespace definitions from the configuration facility 10406, evaluate thesite selections. The simulation facility 10410 may include models 10426.As used herein with respect to site selection, a model includes thecombination of parameters and the values that describe a site selectionand/or corresponding clinical trial designs and the scenario under whichthe site selection is evaluated. Models 10426 may include hundreds oreven thousands of models. Models 10426 may include deviationspecifications for one or more of the parameters of the models. Adeviation specification may define a range of values, a distribution ofvalues, and/or a function of values for one or more parameters of amodel. The deviation specifications may be based on expected orpreviously measured distributions or variations in design parameters.

The simulation facility 10410 may include engines 10428. As used herein,engines may relate to the codification of a site selection and/orcorresponding clinical trial design that can receive model parametersand run a simulation to generate an output. The output of the engines10428 may be a predicted behavior for a site selection for one or morecorresponding clinical trial designs and/or one or more scenarios and/orconditions. Engines 10428 may evaluate a site selection with analyticalmethods, mathematical methods, numerical methods, simulation, and/or thelike. Evaluating a site selection may include a simulation run todetermine performance of the site selection. Evaluating a site selectionmay include using a Monte Carlo approach to simulate a site selectionfor different values according to the deviation specifications and usingstatistical methods to determine the performance of the site selectionfrom a simulation run.

The simulation facility 10410 may include search/exploration component10430. The search/exploration component may facilitate modification ofmodel parameters for simulation. The search/exploration component 10430may adaptively modify or generate models for simulations based onsimulation results of other models/site selections and/or based ontriggers and data from other facilities of the platform 10404.

The analysis facility 10408 may be configured to analyze simulationresults of site selections. The analysis facility 10408 may include afiltering component 10420. The filtering component 10420 may beconfigured to use one or more numerical and/or analytical methods toevaluate and compare the performance of evaluated site selections. Thefiltering component may identify optimal or near-optimal site selectionsfor one or more performance parameters. The filtering component maysearch the performance space and identify a set of optimal and/or nearoptimal site selections for one or more performance parameters.

The analysis facility 10408 may include a recommendation component10422. The recommendation component 10422 may provide site selectionrecommendations. The site selection recommendations may be based onoptimal or near-optimal site selections determined by the filteringcomponent 10420. Recommendations may be adaptive based on settings,feedback, selections, triggers, and the like from the user, and/or otherfacilities in the platform 10404.

The analysis facility 10408 may include an augmenting component, 10424.The augmenting component may supplement simulation results withreal-world data.

The interfaces facility 10412 may be configured to providevisualizations and interfaces for comparing, searching, and evaluatingsimulated site selections. Visualization component 10432 may provide forone or more interfaces to visualize the performance of site selectionsand facilitate comparison of site selections by a user. The feedbackanalysis component 10434 may track user actions associated with theinterfaces and visualizations to determine patterns and/or preferencesfor site selections. The tradeoff advisor component 10436 may analyzeand provide data and guidance for evaluating tradeoffs between two moresite selections.

The platform 10404 may include and/or provide access to one or more datafacilities 10438. Data in the data facilities may include designhistories 10440, simulation data 10442, site data 10444, resource data10446, population data 10448, and the like.

FIG. 105 shows aspects of an embodiment of a process for site selection.The process may include four or more stages. Facilities of the platform10404 may be configured to implement the stages of the process. Thestages of the process may include a configure stage 10502. The configurestage 10502 may define one or more of the spaces associated with thesite selection. The configure stage 10502 may define one or more of siteselection criteria space 10510, site selection design space 10512, siteselection scenario space 10514, and/or site selection performance space10516. The configure stage 10502 may utilize one or more advisors,wizards, algorithms, and the like for defining the spaces. In someembodiments, the different spaces associated with the configurationstage 10502 may be defined by different members of a team based on theexpertise of the members. In some cases, members of a team may havedifferent specializations. For example, some members may specialize inscenarios, while others may specialize in site selection and/or designdefinitions. Separating the inputs may allow different team members toindependently optimize and improve specific models without affectingother inputs. In some embodiments, the inputs may be separated into twoor more types based on convenience, expertise, flexibility, and thelike.

The stages of the process may include an evaluate stage 10504. Theevaluate stage 10504 may configure models 10518 for evaluation usingsimulation 10520 and analytical methods 10524. The stage may includevarious methods of enhancing computation and simulation usingparallelization and resource management 10522.

The stages of the process may include an augment stage 10506. Theaugment stage 10506 may add real-world data to the simulation data.Financial data 10526, regulatory data 10528, revenue data 10530, and thelike may be added to the and used to augment data from simulations.

The stages of the process may include an explore and analyze stage10508. The explore and analyze stage 10508 may include filtering methodsand algorithms 10532 for identifying optimal site selections. The stagemay include generating and interacting with visualizations 10534 andtradeoff analysis tools 10534 to compare and select site selections.

In embodiments, the platform 10404 (FIG. 104) may be configured foridentification and confirmation of optimal site selections for aclinical trial. Optimality of site selection may be in relation to siteselection criteria, e.g., a parameter within site selection criteriaspace 10510 (FIGS. 105 and 106). For example, embodiments of the currentdisclosure may provide for the determination of a site selection for aclinical trial as being the most likely site selection to result in thehighest number of diabetic patients being recruited to participate inthe clinical trial. Site selection criteria may be determined inrelation to the site selection performance space 10514 (FIGS. 105 and106). Optimality of the site selection criteria may be in relation toone or more site selection performance parameters, e.g., a parameterwithin site selection performance space 2414, and the values thereof. Anoptimal site selection may be a site selection that achieves a mostdesirable value for one or more specific site selection performanceparameters. A most desirable value may depend on the site selectionperformance parameter and may be different for each site selectionperformance parameter. In some cases, the most desirable value may bethe highest value of a site selection performance parameter. In somecases, the most desirable value may be the lowest value of a siteselection performance parameter. In some cases, the most desirable valuemay be a range of values, a specific value, a function of values, andthe like. For example, in some cases an optimal site selection withrespect to a cost site selection performance parameter may be a siteselection that has the lowest cost and achieves the goals of theclinical trial. As another example, an optimal site selection withrespect to a time site selection performance parameter may be a siteselection that has the highest NPV and achieves the goals of theclinical trial.

In embodiments, an optimum site selection is a site selection thatachieves most desirable values for two or more specific site selectionperformance parameters. In the case of optimality for multiple siteselection performance parameters, optimality may require a tradeoffbetween the parameter values. For example, a site selection that has alower cost may have a low NPV and therefore may not be desirable. Theoptimality of a site selection may be based on a function of siteselection performance parameters. In some cases, a function may be aweighted sum of the site selection performance parameters. A function,or a set of functions, may be used to generate an overall score (or aset of scores) and the score may be used to determine the optimality ofthe site selection. A highest score, a specific score, lowest score, andthe like may be considered optimal depending on the function used tocompute the score.

In embodiments, optimality may be evaluated according to Paretooptimality. Pareto optimal site selections may be site selections whereno individual site selection performance parameter can be better offwithout making at least one other individual site selection performanceparameter worse off. In some cases, optimality may be determined usingconvex hull analysis.

In some cases, one site selection may be globally optimum. In somecases, more than one site selection may be globally optimum. In somecases, no site selections may be globally optimum. In some embodiments,optimality of site selection may be relative to a benchmark. A knownsite selection, a set of historical site selections, and/or the like maybe used as a benchmark. Site selections may be considered optimal ifthey meet, exceed, and/or are within a threshold distance of thebenchmark site selection performance parameters.

Site selection performance parameters that may be used to determine siteselection optimality may be user defined, system defined,algorithmically defined, and/or the like. In some cases, users mayspecify a subset of site selection performance parameters that should beused to identify optimal site selections. A user may define optimalitycriteria by defining ranges, values, characteristics, and the like ofthe parameter values that may be considered desirable and/or optimal.Interactive graphical interfaces may be provided to a user to evaluatedifferent site selections based on one or more optimality criteria.Interactive interfaces may allow a user to explore different siteselections by changing scoring methods, weights associated with thecriteria, and the like.

In embodiments, the characteristics of site selection performanceparameters for evaluated site selections may be analyzed by the platformto determine if any of the parameters may be less important foroptimality. For example, analysis may include evaluation of ranges,variability, and other statistical analysis. If one or more siteselection performance parameters for all evaluated site selections iswithin a desirable range, or the site selection performance parameter isalmost equal for all of the evaluated site selections, the siteselection performance parameter may be removed and identified as lesssignificant for optimality and, in some cases, may not be factored inwhen determining optimality. Prior to determining optimality based onsite selection performance parameters, the site selection performanceparameters and the values of the site selection performance parametersmay be grouped, filtered, normalized, and the like.

Optimality of site selections may be redefined automatically,semi-automatically, in response to user input, and/or the like. Thecriteria for optimality of site selections may change as site selectionsare evaluated by the platform. For example, initial optimality criteriamay produce no optimal site selections. In response to no optimal siteselections being determined, the criteria may be changed (relaxed,increased, decreased, etc.) until at least one site selection isconsidered optimal. In another example, optimality criteria may changein response to user feedback. Users may evaluate initial site selectionsfound to be optimal and provide feedback (direct feedback and/orindirect feedback that can be derived from user actions and inactions).The feedback from the user may be used to change how optimality isdetermined, which site selection performance parameters are used todetermine optimality, the values of the site selection performanceparameters that are considered optimal, and/or the like.

In some embodiments, site selection performance parameters may begrouped, ordered, and/or organized into one or more hierarchies, groups,and/or sets. Two or more different optimality criteria may be used inparallel to determine multiple sets of optimal site selections underdifferent criteria. Two or more different optimality criteria may beused sequentially to determine optimal site selections. One criteria mayfirst be used to identify a first set of optimal site selections underfirst criteria. A second set of criteria may then be used on the firstset to reduce the set of optimal site selections.

In embodiments, a site selection may be globally optimum if the siteselection is optimal with respect to all possible site selectionoptions. In embodiments, a site selection may be globally optimum if thesite selection is optimal with respect to possible site selectionoptions for one or more criteria. In embodiments, a site selection maybe globally optimum if the site selection is optimal with respect to alarge percentage (such as 80% or more) of possible site selectionoptions for one or more criteria. In embodiments, a site selection maybe globally optimum if the optimality of the site selection is within ahigh confidence level (90% confidence) with respect to possible siteselection options for one or more criteria.

Traditional methods for evaluating site selections cannot determineglobal optimum site selections since they evaluate one, several, or asmall subset of site selection options. Traditional methods do notconsider all or almost all of the site selection options and cannot finda global optimum.

Trial site selections may involve numerous variables, parameters,considerations, tradeoffs, and the like resulting in a very large numberof possible variations. A large number of possible variations makesstudy site selections and optimization using traditional methodsdifficult. In many cases, traditional methods may fail to explore orconsider the complete space of possible trial site selection options andmay miss or never consider globally optimal site selections. Usingtraditional methods, the number of site selection variations that may beexplored in a reasonable time is limited. In some cases, only one (1)statistical site selection and only three (3) clinical scenarios may beevaluated. The best site selection study of the limited number ofvariations may not result in a globally optimal site selection. Alocally optimum site selection chosen from a limited number ofconsidered site selections may represent one (1) local maximum but maybe far from the globally optimum site selection. When 10,000 or moreclinical scenarios are considered, a globally optimum site selection maybe distinguished from the many locally optimum site selections. However,consideration of 10,000 clinical scenarios cannot be practicallyperformed using traditional methods as it would require an estimated50,000 hours or more to complete.

In embodiments, the platform and methods described herein may evaluatethousands or even millions of site selection options enabling adetermination of a global optimum site selection. In many cases, theglobally optimum site selection may have significant advantages overlocally optimum site selection. In one example, a globally optimum siteselection may require less time to complete than other site selections.

In embodiments optimization of trial site selections may occursequentially after optimization of trial design. In one embodiment, aglobally optimum trial design may be determined using the techniquesdescribed herein. After the globally optimum trial design is determineda globally optimum trial site selection may be determined for thedetermined trial.

Referring again to FIG. 104, the platform 10404 may receive and/ordetermine performance space using the configuration facility 10406.Performance space may be defined in the space definitions component10416. The performance space may be configured based on input from usersand/or based on data 10438 such as history data 10440 and/or simulationdata 10442. In embodiments data 10438 may include external data fromexternal data sources and providers. In one instance, performance spacemay define optimality criteria. Optimality criteria may define siteselection performance parameters, performance values, functions,methods, and algorithms for evaluating optimality and/or globaloptimality of site selections. In one instance optimality criteria maybe configured by the user or determined from benchmark site selectionsfrom history 10440 and/or simulation 10442 data. In another instance,optimality criteria may be defined from simulation data from thesimulation facility 10410. Optimality of site selections may bedetermined in the analysis facility 10408. The filtering component 10420may be used to determine one or more sets of globally optimum siteselections from the site selections evaluated by the simulation facility10410.

FIG. 106 shows aspects of an apparatus/optimality analysis component10602 for determining global optimality of site selections. Inembodiments, the optimality analysis component 10602 may be part of theanalysis facility 10408 of the platform 10404. The optimality analysiscomponent 10602 may receive data from simulated site selections 10612and determine one or more sets of optimal site selections 10622, 10624.The optimality analysis component 10602 may include one or more circuitsfor determining optimality of site selection. In embodiments, theoptimality analysis component 10602 may include circuits for determiningoptimality based on optimality functions 10628. Optimality functions10628 may determine optimality of site selections based on differentweighting of performance factors of the simulated site selections. Inembodiments, the optimality analysis circuit 10602 may include circuitsfor determining optimality based on benchmark analysis 10604. Abenchmark analysis circuit 10604 may determine optimality of siteselections based on a comparison of site selection performance parametervalues to one or more benchmark site selections such as from historicaldata 10614 and/or simulation data 10612. In embodiments, the optimalityanalysis circuit 10602 may include circuits for determining optimalityusing sequential analysis 10608 and/or parallel analysis 10610. Thesequential analysis circuit 10608 and parallel analysis circuit 10610may use one or more different optimality functions 10628 in parallel orsequentially to determine optimal site selections. In embodiments, theoptimality analysis circuit 10602 may include circuits for dynamicallymodifying optimality criteria 10606. User inputs 10620, simulation data10612, and/or the determined sets of optimal site selections may bemonitored and analyzed to determine modifications to optimalitycriteria. In embodiments, the optimality analysis circuit 10602identifies a confidence level 10626 associated with the optimality ofsets of optimal site selections. In the case where simulation data 10612may not include simulations of all site selection options for thecriteria space 10618, the optimality circuit 10602 may determine, basedon the simulated site selections, a confidence level that the determinedoptimal site selections are indeed optimal for a given optimalitycriteria.

FIG. 107 shows aspects of an apparatus 10700 for determining globaloptimality of site selections. In embodiments, the apparatus 10700 mayinclude an optimality analysis circuit 10714 which may be part of theanalysis facility 10408 of the platform 10404 (FIG. 104). Inembodiments, the apparatus 10700 may include a data processing circuit10706 structured to interpret/obtain site selection data 202 of aclinical trial site selection. In some embodiments the site selectiondata 202 may be outputs of simulation data of trial site selections. Theoutput processing circuit 10706 may transform the site selection data10702 into a format suitable for use by the various circuits in theapparatus. For example, the site selection data 10702 may be received bythe data processing circuit 10706 and determine and identify siteselection performance parameters in the data. In some embodiments, somesite selection performance parameters may be grouped, filtered,converted, normalized, and the like.

The apparatus 10700 of FIG. 107 may further include an optimalitydetermining circuit 10708 structured to receive processed site selectiondata from the data processing circuit 10706. The optimality determiningcircuit 10708 may identify globally optimum site selections 10712 basedon one or more optimality criteria. In some embodiments, the globallyoptimum site selections 10712 may be provided as an output of theapparatus. In some embodiments, globally optimum site selections 10712may be further processed by the site selection analysis circuit 10710.The site selection analysis circuit 10710 may analyze the globallyoptimum site selections 10712, determine characteristics of the siteselections, and receive feedback data 10704 about the site selections.The site selection analysis circuit may, based on the determinedcharacteristics, determine modifications for optimality criteria used inthe optimality determining circuit 10708. Using modified optimalitycriteria, the optimality determining circuit 10708 may determine a newset of globally optimum site selections 10712.

As shown in FIG. 108, a method 10800 for determining globally optimumsite selections may include simulating all site selection options for asite selection criteria 10802. The method 10800 may further includedetermining an optimality criteria for evaluating simulated siteselections 10804. Optimality criteria may be a function of one or moreperformance values for each site selection such as a weighted sum of thevalues, a comparison of the values, and the like. The method 10800 mayinclude searching for globally optimum site selections in the simulatedsite selections using the determined optimality criteria 10806. Theglobally optimum site selections may be recommended to one or more users10808.

As shown in FIG. 109, a method 10900 for determining globally optimumsite selections may include simulating site selection options for a siteselection criteria 10902. The method 10900 may further includedetermining a first optimality criteria for evaluating simulated siteselections 10904. The method 10900 may further include determining asecond optimality criteria for evaluating simulated site selection(s)10906. The method 10900 may include determining a first set of optimumsite selections using the first optimality criteria, the first set maybe determined from the simulated site selections 10908. The method 10900may further include determining a second set of optimum site selectionsusing the second optimality criteria, the second set may be determinedfrom the first set of site selections 10910. The globally optimum siteselections may be recommended to one or more users 10912.

As shown in FIG. 110, a method 11000 for determining globally optimumsite selections may include simulating site selection options for a siteselection criteria 11002. The method 11000 may further includedetermining a first optimality criteria for evaluating simulated siteselections 11004. The method 11000 may include determining a first setof optimum site selections using the first optimality criteria, thefirst set may be determined from the simulated site selections 10906.The method 11000 may further include identifying characteristics of siteselections in the first set of globally optimum site selections 11008.The method 11000 may further include determining a second optimalitycriteria for evaluating simulated site selections based on theidentified characteristics 11010. The method 11000 may includedetermining a second set of globally optimum site selections using thesecond optimality criteria from the simulated site selections 11012.

Illustrated in FIG. 111 is a method 11100 for determining a siteselection to globally optimize patient recruitment for a clinical trial,in accordance with an embodiment of the current disclosure. The method11100 includes determining a plurality of possible sites for recruitingpatients from for a clinical trial 11110. The method 11100 furtherincludes determining, for each of one or more subgroupings of theplurality of possible sites, a predicted patient recruitment value11112. The method 11100 further includes determining which subgroupingof the plurality of possible sites has a predicted patient recruitmentvalue that globally optimizes a desired site selection criteria 11114.In embodiments, determining the predicted patient recruitment value foreach of the subgroupings of the plurality of possible sites includessimulating each of the subgroupings 11116. In embodiments, simulatingeach of the one or more subgroupings may be based at least in part onuse of different types of engines, e.g., engines with different versionnumbers and/or developed by different entities, e.g., in-house vsthird-party vendor. In embodiments, the differences in types of enginesmay include underlying types of algorithms and/or assumptions, e.g.,rounding rules. In embodiments, the method 11100 may further includedetermining one or more site selection parameters 11118. In suchembodiments, simulating each of the one or more subgroupings 11116 maybe based at least in part on the one or more site selection parameters.In embodiments, the one or more site selection parameters may be basedat least in part on: a country; a state/province; a county; a city; azip code; and/or a patient enrollment matriculation number. Inembodiments, the method 11100 may further include determining thedesired site selection criteria 11120. In such embodiments, simulatingeach of the one or more subgroupings 11116 may be based at least in parton the determined site selection criteria. In embodiments, thedetermined site selection criteria may be based at least in part on: anumber of required patients; a start date of the clinical trial; an enddate of the clinical trial; and/or a total cost of the clinical trial.In embodiments, determining which subgrouping of the plurality ofpossible sites has a predicted patient recruitment value that globallyoptimizes the desired site selection criteria 11114 may include and/orbe based at least in part on: a convex hull engine; a Pareto engine; aMonte Carlo engine; and/or a simulated annealing engine. In embodiments,determining which subgrouping of the plurality of possible sites has apredicted patient recruitment value that globally optimizes the desiredsite selection criteria 11114 may be based at least in part on a machinelearning engine, as described herein. For example, in embodiments, aneural network may be trained to look at past site selections and theiroutcomes and predict one or more site selection criteria. Inembodiments, the neural network may be trained via supervised learningand/or by unsupervised learning, e.g., cost-based policies.

Turning to FIG. 112, an apparatus 11200 for determining a site selectionto globally optimize patient recruitment for a clinical trial, inaccordance with an embodiment of the current disclosure, is shown. Theapparatus 11200 may form part of the platform 10404 or it may bestand-alone from the platform 10404 and/or communicate with the platform10404 via one or more application programming interfaces (APIs). Theapparatus 11200 includes a site selection data processing circuit 11210structured to interpret possible site selection data 11212 identifying aplurality of possible sites for recruiting patients from for a clinicaltrial. The apparatus 11200 further includes a patient recruitmentdetermination circuit 11214 structured to determine a predicted patientrecruitment value 11216 for each of one or more subgroupings of theplurality of possible sites. The apparatus 11200 further includes a sitesearching circuit 11218 structured to determine which subgrouping 11220of the plurality of possible sites has a predicted patient recruitmentvalue that globally optimizes a desired site selection criteria 11230.The apparatus 11200 further includes a site selection provisioningcircuit 11222 structured to transmit the subgrouping 11220 of theplurality of possible sites that has the predicted patient recruitmentvalue that globally optimizes the desired site selection criteria. Inembodiments, the patient recruitment determination circuit 11214 isfurther structured to determine the predicted patient recruitment valuefor each of the one or more subgroupings of the plurality of possiblesites by simulating each of the subgroupings. In embodiments, simulatingeach of the one or more subgroupings is based at least in part on use ofdifferent types of engines, as described herein. In embodiments, theapparatus 11200 may include a user input circuit 11224 structured tointerpret user input data 11226 and a criteria determining circuit 11228structured to determine the desired site selection criteria 11230 basedat least in part on the user input data 11226. In embodiments, the sitesearching circuit 11218 may include a convex hull engine; a Paretoengine; a Monte Carlo engine; and/or a simulated annealing engine.

Referring to FIG. 113, embodiments of the current disclosure may providefor a design platform 11300 with an interface 11310 for configuring andmanaging the platform 10404 with respect to optimizing site selectionfor patient recruitment for a clinical trial. The design platform 11300may provide for pre-simulation determination of one or more selectionparameters, e.g., values within site selection criteria space 10510,site selection space 10512, site selection scenario space 10514 and/orsite selection performance space 10516. Some embodiments may provide foradjustment of selection parameters during a simulation. The interface11310 may include a canvas area 11312 for visualizing/editing/creatingselection parameters for use by the platform 10404 (FIG. 104).Embodiments of the interface 11310 may be a graphical user interface(GUI) that has one or more input fields 11314 for inputting or selectingselection parameters. The input fields 11314 may be sliders, text boxes,moveable components, and/or other GUI user input widgets. The graphicaluser interface may also provide for a heat map for selecting possiblesites. The heat map may provide for filtering of the possible sites. Inembodiments, the platform 11300 may provide, via servers 10454 (FIG.104) multiple interfaces, e.g., interfaces 11310, 11316, 11318, forcollaborative configuration of the platform 10404 by one or more users.In embodiments, the interfaces 11310, 11316, 11318 may be configureddifferently for different users, e.g., an interface may be tailored to atype of user and/or target audience, e.g., clinical trial experts,novices, and/or other types of users of varying skill levels in clinicaltrial designs and/or site selection. Tailoring of an interface to a usertype may include enabling and/or disabling certain features and/oroptions on the interface. In embodiments, collaboration between usersmay involve a first user operating on a first interface 11310 receivinginputs from a second interface 11316 operated by a second user. Inembodiments, the interface 11310 may provide for weighting of one ormore selection parameters. In embodiments, the interface 11310 mayprovide for configuration of the simulation component 10410 (FIG. 104).For example, a user operating the interface 11310 may configure thesimulation component 10410 to perform an exhaustive search and/orsimulation of site selection options. In embodiments, a user operatingthe interface 11310 may configure the simulation component 10410 toperform a non-exhaustive search and/or simulation of site selectionoptions. In embodiments, the interface 11310 may provide for a user toconfigure the platform 10404 to user one or more of a convex hullengine, a Pareto engine, a Monte Carlo engine, and/or simulatedannealing engine. In embodiments, the interface 11310 may provide for auser to configure a training set for a machine learning engine to learnhow to optimize site selections with respect to patient recruitment, asdisclosed herein.

Turning to FIG. 114, a method 11400 for collaborative configuration of asite selection platform 10404 for optimization of patient recruitmentfor a clinical trial is shown. The method 11400 includes displaying agraphical user interface structured to configure a system fordetermining which subgrouping, of a plurality of possible sites forrecruiting patients from for a clinical trial, globally optimizes adesired criteria 11410. The method further includes receiving, via thegraphical user interface, one or more user inputs that define one ormore selection-parameters used by the system 11412. The method furtherincludes storing the defined selection-parameters in a memory device11414.

Shown in FIG. 115 is an apparatus 11500 for providing collaborativeconfiguration of a site selection platform 10404 for optimization ofpatient recruitment for a clinical trial is shown. The apparatus 11500includes a display generation circuit 11510 structured to generate agraphical user interface 11512 for configuring a system 10404 fordetermining which subgrouping, of a plurality of possible sites forrecruiting patients from for a clinical trial, globally optimizes adesired criteria. The apparatus 11500 further includes a displaytransmission circuit 11514 structured to transmit the graphical userinterface 11512 to an electronic device for display, e.g., 10402 (FIG.104). The apparatus 11500 further includes a user interaction circuit11516 structured to: interpret user inputs 11518 received by thegraphical user interface 11512; and in response to, and based at leastin part on, interpreting the user inputs 11518, define selectionparameters 11520 used by the system 10404. The apparatus 11500 furtherincludes a selection-parameter provisioning circuit 11522 structured tostore the defined selection-parameters 11520 in a memory device, e.g.,10438 (FIG. 104).

Shown in FIG. 116 is another method 11600 for collaborativeconfiguration of a site selection platform 10404 for optimization ofpatient recruitment for a clinical trial. The method 11600 includesconfiguring, via a graphical user interface, a recruitment siteselection system via entering one or more user inputs into the graphicaluser interface that define one or more selection-parameters 11610. Themethod 11600 further includes determining, via the recruitment siteselection system, which subgrouping, of a plurality of possible sitesfor recruiting patients from for a clinical trial, globally optimizes adesired criteria 11612. The method further includes transmitting dataidentifying the determined subgrouping 11614.

Referring to FIG. 117, embodiments of the disclosure may provide for aplatform/system 11700 with an interface 11710, e.g., a wizard, forguiding a user through configuring a site grouping/selectionsystem/platform 10404 (FIG. 104) for optimizing site selection forpatient recruitment for a clinical trial. In embodiments, the interface11710 may be generated by a server 10454 (FIG. 104). The interface 11710may be command line based or graphical user interfaced based. Theinterface 11710 may generate a plurality of prompts 11712 that assist inobtaining initial selection parameters, e.g., criteria, from users todetermine parameters for site selection criteria space 10510, siteselection space 10512, site selection scenario space 10514, and/or siteselection performance space 10516. The plurality of prompts 11712 mayask for a variety of static inputs or ranges. The inputs may include thetype of engine 10428 to use in the simulation 10410. The inputs may alsoinclude the type of search algorithm 10430 used. The inputs may includethe type of sensitivity analysis algorithms or tools that are preferred.The inputs may include the type of clinical trial. The interface 11710may recommend one or more site groupings/selections based on the type ofclinical trial. The recommended site groupings/selections may serve as astarting base for further modification by a user. Artificialintelligence/machine learning approaches may be used to generate theprompts 11712 and/or suggestions for the user through the configurationprocess. As will be appreciated, the suggestions and/or guiding by theinterface 11710 may allow a user to avoid (or reduce) spending time andresources (including computing resources and the costs of thoseresources) on sub-optimal simulations.

In an embodiment, a method for guiding a user through configuring a sitegrouping/selection system/platform for optimizing site selection forpatient recruitment for a clinical trial is provided. The methodincludes generating an interactive interface. The method furtherincludes presenting, via the interactive interface, a plurality ofprompts to a user structured to configure a site selection system fordetermining which subgrouping, of a plurality of possible sites forrecruiting patients from for a clinical trial, globally optimizes adesired criteria. The method further includes for each of the pluralityof prompts, receiving a responsive user input, and configuring the siteselection system based at least in part on the responsive user inputs.

In another embodiment, a system for guiding a user through configuring asite grouping/selection system/platform for optimizing site selectionfor patient recruitment for a clinical trial is provided. The systemincludes a server structured to determine which subgrouping of aplurality of possible sites for recruiting patients from for a clinicaltrial globally optimizes a desired criteria. The system further includesan electronic device, e.g., 10402, structured to: display an interactiveinterface that presents a plurality of prompts to a user for configuringthe server; for each of the plurality of prompts, receive a responsiveuser input; and configure the server based at least in part on theresponsive user inputs.

In another embodiment, a non-transitory computer readable medium storinginstructions is provided. The stored instructions, when loaded into atleast one processor, adapt the at least one processor to: generate aninteractive interface; and present, via the interactive interface, aplurality of prompts to a user. The plurality of prompts are structuredto configure a site selection system for determining which subgrouping,of a plurality of possible sites for recruiting patients from for aclinical trial, globally optimizes a desired criteria. The storedinstructions further adapt the at least one processor to, for reach ofthe plurality of prompts, receive a responsive user input; and configurethe site selection system based at least in part on the responsive userinputs.

Embodiments of the current disclosure may provide for prediction of aninitial site grouping/selection with respect to patient recruitment of aclinical trial. In embodiments, the initial site selection may bestructured to maximize (globally optimize) one or more desired criteria,e.g., one or more parameters within site selection criteria space 10510,site selection space 10512, site selection scenario space 10514, and/orsite selection performance space 10516, based on historical data. Forexample, in embodiments, a predicted initial site selection maycorrespond to maximizing a number of patients with a particular medicalcondition. In other embodiments, the predicted initial site selectionmay correspond to maximizing the number of recruited patients who arelikely to complete the clinical trial.

In embodiments, the historical data may include data from previouslyconducted clinical trials and/or it may include data from priorsimulated clinical trials. In embodiments, the data may be stored indata facility 10438 and/or be generated by the simulation component10410 and/or the analysis components 10408. Data from past trials may beused to directly predict aspects of sites. Data from past trials may beused as a guide to determine parameters of the trials that weresuccessful since in many cases, past indicators of success may translateto future success. For example, sites identified as having a highhistorical recruitment rate may generally be expected to have highrecruitment rate for a future study. However, in some cases, dependingon the parameter, a high success rate in historical data may translateto a negative or less favorable prediction for the current siteselection. For example, a site as having a historical high recruitmentfor patients with a rare disease may translate to a prediction for lowrecruitment of the same type of patients for a new study. In some cases,depending on the therapeutic tested, a waiting period for the patientsinvolved in the previous study may be required before they are allowedto participate in a new study making the patients unavailable for a newstudy. Therefore, an indication of high success in historical data mayindicate that the patients will not available and may indicate a lowperformance for a planned study in the site. In embodiments, models forsite selection may be evaluated for negative and positive associationsbetween historical performance and expected current performance.

The prediction may be generated prior to receiving user input or afterreceiving some user input e.g., via user device 10402. The predictedinitial site grouping/selection may be displayed in a graphical userinterface, e.g., interface component 10412, for adjustment by a user.The predicted initial site grouping/selection may be thegrouping/selection actually used in the clinical trial, or it may serveas a starting point which the user can configure/tweak as desired. Thepredicted initial site grouping/selection may be the global optimal,with respect to the desired site selection criteria; or it may be closeto the global optimal, wherein a user can tweak it, i.e., makeadjustments, to be the global optimal. The initial prediction may reducethe amount of time to find the global optimum by providing the user (orcomputer) with a good starting point based on knowledge gained fromhistorical data. Simulated annealing, e.g., via the search/explorationmodules/engines 10430, may be applied to the initial prediction to testthe surrounding subgroupings. Artificial intelligence may be used toanalyze the historical data based on known desired criteria for theclinical trial. For example, in embodiments, a neural network may betrained on historical data to identify patterns in site selections thatresult in particular values for one or more site selection criteria. Theneural network may then process site selection data, i.e., dataregarding possible sites for a clinical trial, and then generate apredicted initial site selection.

Accordingly, referring to FIG. 118, a method 11800 for prediction of aninitial site grouping/selection with respect to patient recruitment of aclinical trial is shown. The method 11800 includes accessing past trialsite selection data stored in a database 11810. The method 11800 furtherincludes predicting, based at least in part on the past trial siteselection data, the initial site selection 11812. In embodiments,predicting the initial site selection may be based at least in part onartificial intelligence, as disclosed herein. The initial site selectionmay correspond to a global optimization of a desired site selectioncriteria. The method 11800 further includes evaluating the initial siteselection with respect to being the global optimization (with respect tothe desired site selection criteria) 11814. Such evaluation may be basedat least in part on a convex hull engine, a Pareto engine, a Monte Carloengine, or a simulated annealing engine, as disclosed herein. The method11800 may further include displaying the initial site selection in agraphical user interface 11816. In embodiments, the desired siteselection criteria may include a number of required patients; a startdate of the clinical trial; an end date of the clinical trial; and/or atotal cost of the clinical trial. In embodiments, the desired siteselection criteria may be based at least in part on a patientrecruitment related number, e.g., a minimum and/or maximum number ofpatients required to be recruited by the clinical trial guidelines, aminimum number of patients required to complete the clinical trial,and/or the like. In embodiments, the method 11800 further includesadjusting the initial site selection via the graphical user interface11818. In embodiments, the method 11800 may further include interpretingone or more user inputs, wherein the prediction of the initial siteselection is based at least in part on the one or more user inputs11820. In embodiments, the method 11800 may further include simulatingthe initial site selection to determine performance criteria 11822. Inembodiments, the method 11800 may further include conducting asensitivity analysis of the initial site selection 11824, e.g., viaanalysis component 10408.

Illustrated in FIG. 119 is an apparatus 11900 for prediction of aninitial site grouping/selection with respect to patient recruitment of aclinical trial. The apparatus 11900 includes a past trial dataprocessing circuit 11910 structured to interpret past trial siteselection data 11912. The apparatus 11900 further includes a patientrecruitment prediction circuit 11914 structured to generate, based atleast in part on the past trial site selection data 11912, initial siteselection data 11916 for recruiting patients for a clinical trial. Theinitial site selection data corresponds to a global optimization of adesired site selection criteria. The apparatus 11900 further includes apatient recruitment evaluation circuit 11918 structured to evaluate theinitial site selection data with respect to the global optimization. Theapparatus 11900 further includes a prediction provisioning circuit 11920structured to transmit the initial site selection data 11916.

Embodiments of the current disclosure may also provide for a method forusing the initial site selection. The method may include receiving aninitial site selection for recruiting patients for a clinical trial; andconducting a clinical trial based as least in part on the initial siteselection. The initial site selection may correspond to a globaloptimization of a desired criteria, wherein the initial site selectionwas predicted from past trial site selection data. For example, a firstentity may generate initial site selection data and send it to a secondentity that conducts a clinical trial based at least on part on theinitial site selection data.

Referring now to FIG. 120, embodiments of the current disclosure mayprovide for a platform/system 12000 that generates an interactiveinterface 12010, e.g., a GUI, for exploration/evaluation of spacesrelated to patient recruitment for a clinical trial, as opposed tomerely facilitating selection of proposed sites, for the purpose ofglobally optimizing site selection for a clinical trial to achieve adesired patient recruitment, e.g., a maximum number of recruitedpatients. The spaces may include site selection criteria space 10510,site selection space 10512, site selection scenario space 10514, and/orsite selection performance space 10516. In embodiments, generation ofthe site selections and/or evaluation of the spaces may be based atleast in part on convex hull, Pareto frontiers, Monte Carlo, simulatedannealing, and/or machine learning, e.g., artificial intelligence, asdescribed herein.

Exploration/evaluation of the spaces may provide insights to a userregarding known and/or unknown constraints on site selection and/or theimpact a particular selection parameter, e.g., a parameter within one ofthe spaces, may have on patient recruitment.

Exploration of the spaces may be facilitated via visualizations of thespaces. The visualizations may include, and/or be based at least in parton, heatmaps and/or tornado graphs. The interface 12010 may include acanvas area 12012 for rendering (or rasterizing) the visualizations.

The interface 12010 may provide for users to adjust one or moreselection parameters and/or adjust sites within one or more proposedsite selections/groupings and see the effect on the predicted patientrecruitment. Adjustment of the selection parameters may be facilitatedby one or more interactive widgets 12014, e.g., text boxes, buttons,sliders, and/or the like. In embodiments, adjustment of the selectionparameters may be facilitated via the canvas 12012. In embodiments, theinterface 12010 may allow users to evaluate and compare possible siteselections/groupings side-by-side.

In embodiments, exploration of the spaces may provide for sensitivityanalysis. For example, embodiments of the interface 12010 mayincorporate simulated annealing engines, as described herein.

In embodiments, platform/system 12000 may include a server, e.g. server10454 in the computation resources 10450 of platform 10404. The server10454 may generate the interface 12010 as a web application, remotedesktop, and/or other suitable architecture for providing the interface12010 to users and/or user devices 10402.

The platform may support collaboration among different users. Forexample, the server 10454 may generate multiple interfaces 12010, 12016,and 12018. In embodiments, the interfaces 12010, 12016, and 12018 may beconfigured/tailored to different types of user/target audience, e.g.,users with different levels of experience and/or knowledge with respectto evaluating site groupings/selection for various criteria. Forexample, a first interface 12010 for an expert user may have morefunctionality, e.g., access to more options and/or features, than asecond interface 12016 for a novice user.

Turning to FIG. 121, a method 12100 for exploring/evaluating spacesrelated to patient recruitment for a clinical trial is shown. The method12100 includes generating a graphical user interface structured toprovide for interactive exploration of one or more spaces correspondingto one or more selection parameters for determining which subgrouping,of a plurality of possible sites for recruiting patients from for aclinical trial, globally optimizes a desired site selection criteria12110. The method 12100 further includes adjusting at least one of theselection parameters via the graphical user interface 12112. The method12100 further includes updating the graphical user interface in responseto adjusting the at least one selection parameter 12114. In embodiments,the desired selection criteria may be based at least in part on apatient recruitment related number. In embodiments, generating thegraphical user interface occurs prior to simulating, as disclosedherein, any one of the possible sites. In embodiments, generating thegraphical user interface occurs after simulation of one or more of thepossible sites.

Illustrated in FIG. 122 is a non-limiting embodiment of an apparatus12200 for exploring/evaluating spaces related to patient recruitment fora clinical trial. The apparatus 12200 includes a patient recruitmentspace processing circuit 12210 structured interpret space data 12212corresponding to one or more spaces, e.g., 10510, 10512, 10514, and/or10516, related to subgroupings of possible sites for use in conducting aclinical trial. The apparatus 12200 further includes a graphics circuit12214 structured to generate interactive interface data 12216 inresponse to the space data 12212. The interactive interface data 12216may correspond to a computerized interface 12010 for globally optimizinga desired site selection criteria. The apparatus 12200 further includesa user input circuit 12218 structured to receive user input data 12220responsive to the presentation of the interactive interface data 12216.The apparatus 12200 further includes a patient recruitment spaceexploration circuit 12222 structured to modify the interactive interfacedata 12226 in response to the user input data 12220. The apparatus 12200further includes an interactive provisioning 12224 circuit structured totransmit the modified interactive interface data 12226.

Referring to FIG. 123, a method 12300 for updating patient recruitmentis shown. Since recommendation of globally optimal site selection, asdisclosed herein, are generally predictive, it is possible that one ormore parameters used to determine a globally optimum site selection fora clinical trial may deviate from what actually occurs duringconduction/execution of the trial, i.e., while the trial is underway.For example, a globally optimum site selection may have been determinedbased on a recruitment scenario where no major worldwide healthemergencies occur during the duration of the clinical trial, when, inactuality, a global pandemic emerges shortly after the start of aclinical trial. In such a case, the original globally optimum siteselection may no longer be the optimum. Updating of a site selection, asdescribed herein, may occur multiple times through the course/durationof the clinical trial. In some embodiments, updating of the siteselection, as described herein, may be performed on a continuous basisthroughout the duration of the clinical trial.

Accordingly, the method 12300 includes obtaining a first simulationoutput for a first set of site selections for a clinical trial 12310.The first simulation output includes first site selection performanceparameters, as disclosed herein, associated with each design in thefirst set of site selections for a first set of site selection criteria.The method 12300 further includes determining, from the first set ofsite selection criteria, a first optimality criteria for evaluating thefirst set of site selections 12312. The method 12300 further includesdetermining, within the first set of site selections, a first globallyoptimum site selection based at least in part on the first siteselection optimality criteria and the first site selection performanceparameters 12314. Optimum site selections may be determined using one ormore of Pareto analysis, convex hull analysis, and/or simulatedannealing analysis. The site selection may then be configured based atleast in part on the first globally optimum site selection, e.g., thesite selection may be made to conform to the globally optimum siteselection.

As further shown in FIG. 123, the method 12300 may includeconducting/executing the clinical trial based at least in part on thefirst globally optimum site selection 12316. Conduction of the clinicaltrial may be defined by a start/beginning 12318 of the clinical trialand a stop/end 12320 of the clinical trial. In embodiments, the start12318 may be the occurrence of the first patient recruitment. Inembodiments, the start 12318 may be the occurrence of the firstinteraction between administrative personnel (for the clinical trial)and a patient or recruitment site, in respect of the trial. Inembodiments, the start 12318 may be the first occurrence of a patientreceiving a treatment (including receiving a drug). In embodiments, thestop 12320 may be the last occurrence of patient receiving a treatment(including receiving a drug). In embodiments, the stop 12320 may be theoccurrence of the last interaction between administrative personnel (forthe clinical trial) and a patient or recruitment site, in respect of thetrial. The time between the start 12318 and the stop 12320 mayconstitute the duration of the clinical trial as that term is userherein. In embodiments, conduction of the clinical trial may includecommencement of any portion and/or process of the clinical trial whetherperformed in succession and/or intermittently.

After the start 12318 of the clinical trial, but before the stop 12320,the globally optimum site selection may be reassessed. As such, themethod 12300 includes obtaining, during conduction of the clinicaltrial, a second simulation output for a second set of site selectionsfor the clinical trial 12322. The second simulation output includessecond site selection performance parameters associated with each designin the second set of site selections for a second set of site selectioncriteria. In embodiments, the second simulation output may be differentthan the first simulation output. For example, the second simulationoutput may be from another evaluation of the site selections. Inembodiments, the second simulation output may be the same as the firstsimulation output. For example, the first simulation output may bereused. In embodiments, the second site selection performance parametersmay be different than the first site selection performance parameters.For example, the second site selection performance parameters mayinclude more or fewer parameters than the first site selectionperformance parameters. In embodiments, the second site selectionperformance parameters may be the same as the first site selectionperformance parameters. In embodiments, the second set of siteselections may be the same or different than the first set of siteselections. For example, the second set of site selections may includeadditional sites selections and/or have removed site selections ascompared to the first set of site selections. In embodiments, the secondset of site selection criteria may be the same or different than thefirst set of site selection criteria. For example, constraints on theclinical trial and/or site selections may have changed since the start12318.

The method 12300 further includes determining, from the second set ofsite selection criteria, a second site selection optimality criteria forevaluating the second set of site selections 12324. In embodiments, thesecond site selection optimally criteria may be the same or differentfrom the first site selection optimally criteria. For example, a usermay have previously determined the globally optimum site selection withrespect to shortest duration and wish to do so again for the secondglobally optimum site selection. As another example, a user may havepreviously determined the globally optimum site selection with respectto shortest duration and may now wish to determine the globally optimumsite selection with respect to costs.

The method 12300 further includes determining, within the second set ofsite selections, a second globally optimum site selection 12326.Determination of the second globally optimum site selection may be basedat least in part on the second site selection optimality criteria andthe second site selection performance parameters. The method 12300 mayfurther include adjusting the site selection based at least in part onthe second globally optimum site selection 12328. Adjustment of the siteselection may include conforming the site selection to the secondglobally optimum site selection.

Illustrated in FIG. 124 is another method 12400 for updating siteselections. In particular, method 12400 identifies a globally optimumsite selection for a clinical trial after the start 12412 of theclinical trial, but before the end 12414 of the clinical trial, where aninitial globally optimum site selection may not have been determined, orwas not determined by an entity performing method 12400. Accordingly,the method 12400 includes obtaining, during conduction of the clinicaltrial 12416, a simulation output for a set of site selections for theclinical trial 12418. The simulation output includes site selectionperformance parameters associated with each site selection in the set ofsite selections for a set of site selection criteria. The method 12400further includes determining, from the set of site selection criteria, asite selection optimality criteria for evaluating the first set of siteselections 12420. The method 12400 further includes determining, withinthe set of site selections, a globally optimum site selection based atleast in part on the site selection optimality criteria and the siteselection performance parameters 12422. The method 12400 may furtherinclude recommending the globally optimum site selection 12424.

Recommendation may include transmitting the globally optimum siteselections to an entity performing and/or planning the clinical trial.The recommended globally optimum site selections may be the first time aglobally optimum site selection was calculated/determined for theclinical trial, or the globally optimum site selection may be an updateto a previously calculated/determined globally optimum site selection.In embodiments, the method 12400 may not include recommending theglobally optimum site selection, but rather may include adjusting thesite selection based at least in part on the globally optimum siteselection 12426. It is to be understood, however, that embodiments ofthe method 12400 may not include adjusting the site selection trialbased at least in part on the globally optimum site selection. Inembodiments, the method 12400 may include both recommending andadjusting the site selection based at least in part on the globallyoptimum site selection.

In addition to the design of a clinical trial, the success of theclinical trial often depends on the availability of resources needed toconduct the clinical trial, also referred to herein as “resourceavailability”. Non-limiting examples of trial resources include:drugs/drug supply, medical devices, procedures, administrativepersonnel, and/or equipment/devices needed to conduct a clinical trial,and/or the like. Resource availability, in turn, is typically a functionof a site selection.

In some cases, a wrong choice in the selection of sites for a clinicaltrial may reduce resource availability which, in turn, may impact and/orprevent completion of the clinical trial. In some cases, difference inavailable resources between different site selections may result in verydifferent costs, completion times, and/or other performance parametersfor the clinical trial.

The selection of sites for a clinical trial, with respect to optimizingavailable resources, may include considerations and tradeoffs betweenhundreds or even thousands of site selections. For example, differentsite selection options, often have different values for resourceavailability, e.g., the sites of a first site selection may be closer tomedical supply distribution centers than the sites of a second siteselection. Traditionally, consideration of resource availability forclinical trials has been based on heuristics and experiencedprofessionals to determine a set of parameters likely to result in asite selection that produces adequate access to resources. However,traditional approaches are not capable of evaluating more than a handfulof site selection options and corresponding tradeoffs. As a result,traditional approaches to resource availability often miss siteselection options that may result in greater resources availability. Asthe cost of a clinical trial may exceed tens of millions or evenhundreds of millions of dollars and/or may take years to complete, smalldifferences in resources availability between site selections for aclinical trial may result in large impacts on the overall cost and/ortime associated with the clinical trial.

The complexity of site selection with respect to resource availabilityoften requires aspects of statistical expertise, clinical designexpertise, and software expertise, which may not be available in manyorganizations. As such, many organizations fallback on the use ofgeneric site selection methodologies due to their inability to findoptimal or near-optimal site selections with respect to resourceavailability for a particular clinical trial.

Accordingly, embodiments of the current disclosure may provide for aresource optimization platform, systems, and methods for evaluationand/or comparison of site selection options with respect to optimizingresource availability for a clinical trial. In embodiments, evaluationand/or comparison may include a large number of site selection options.In some embodiments, the platform, systems, and methods described hereinmay be used to evaluate hundreds, thousands, or even millions of siteselection options for a clinical trial and may be used to find theoptimal or near-optimal resource availability for a trial.

The resource optimization platform may be used for site selection. Inembodiments, a resource optimization platform may support a team, asdescribed herein, in collaborating and surfacing all the inputs that arekey to consider for preparing and selecting a site selection to optimizeavailable resources. The resource optimization platform may use cloudand distributed computing so the team can simulate hundreds of millionsof site selection variants/options across all those inputs. The resourceoptimization platform may present the team with prioritized options andvisualizations to enable the interrogation of the drivers of value. Inan embodiment, available clinical trial resources may have an initialdistribution across one or more sites. For example, a first site mayhave forty (40) kg of a drug and a second site may have twenty (20) kgof a drug. In embodiments, the platform may determine a site selectionbased on the initial distribution of one or more available clinicaltrial resources. In embodiments, the platform may determine one or moreadjustments to the initial distribution to optimize availability of theone or more clinical trial resources and/or site selection. Inembodiments, the adjustments to the initial distribution may facilitatea different clinical trial design and/or a different type of clinicaltrial design that was not previously possible given the initialdistribution of the one or more available clinical trial resources. Inembodiments, the platform may recommend adjustments to the initialdistribution.

A resource optimization platform may enable a team to quickly identifysite selections that optimize available resources and the factors thatmost strongly drive performance factors, strategic goals, and the like.A resource optimization platform, as described herein, may leverageemerging technologies to provide options for advanced simulations,distributed computing, visualizations, and the like. The resourceoptimization platform may leverage methodological knowledge, analysis ofthe business value of different design choices, and/or analysis ofregulatory risk and operational complexity to determine optimum or nearoptimum site selections with respect to resource availability. Theresource optimization platform may determine optimum or near optimumsite selections by leveraging a novel workflow, speed and/or computinginnovations, and/or powerful visualizations for study analysis andoptimization.

A resource optimization platform may improve how data and processes areused to make better decisions on site selections. Improvements mayresult from recognizing which innovative options might significantlyincrease goals. Improvements may be obtained by communicating thebenefits of specific site selections in a way that that intuitivelyallows a variety of team members to understand a particular siteselection and/or possible options for the site selection of a clinicaltrial. A resource optimization platform may support a team incollaborating and surfacing all the inputs that are key to consider forpreparing and selecting an optimal site selection. The resourceoptimization platform may present the team with prioritized options andinsightful visualizations to enable interrogation of the drivers ofvalue.

FIG. 125 shows an embodiment of a platform/system for evaluation andcomparison of site selections with respect to optimizing resourceavailability for a clinical trial. The platform 12504 may form part ofthe platform 104 (FIG. 1) or the platform 12504 may be stand-alone fromthe platform 104. In embodiments, the platform 12504 may communicatewith the platform 104 via one or more application programming interfaces(APIs). The platform 12504 may provide for a system for providing userswith facilities and methods for determining, evaluating, and/orcomparing site selections with respect to resource availability. Thefacilities described herein may be deployed in part or in whole througha machine that executes computer software, modules, program codes,and/or instructions on one or more processors, as described herein,which may be part of or external to the platform 12504. Users mayutilize the platform 12504 to, with respect to optimization of resourceavailability for a clinical trial, identify site selections forcriteria, evaluate the site selections, compare site selections,determine optimal site selections, and the like.

A user may interact with the platform 12504 through one or more userdevices 12502 (e.g., computer, laptop computer, mobile computing device,and the like). The platform 12504 may be implemented and/or leverage oneor more computing resources 12550 such as a cloud computing service12552, servers 12554, software as a service (SaaS), infrastructure as aservice (IaaS), platform as a service (PaaS), desktop as a Service(DaaS), managed software as a service (MSaaS), mobile backend as aservice (MBaaS), information technology management as a service(ITMaaS), and the like. The platform 12504 may be provided or licensedon a subscription basis and centrally hosted (e.g., accessed by usersusing a client (for example, a thin client) via a web browser or otherapplication, accessed through or by mobile devices, and the like). Inembodiments, elements of the platform 12504 may be implemented tooperate on various platforms and operating systems. In embodiments,interfaces for the user device 12502 through which the users mayinteract with the platform may be served to the user device 12502through a webpage provided by a server of the platform 12504, anapplication, and the like.

The platform 12504 may include one or more facilities such as aconfiguration facility 12506, simulation facility 12510, analysisfacility 12508, interfaces facility 12512, data facility 12538, andcomputation resources 12550.

The configuration facility 12506 may include advisors 12514, which mayinclude one or more wizards, tools, algorithms, recommenders,configuration elements, questioners, and the like. Advisors may be usedto receive data and/or define or develop space definitions 12516.

Space definitions 12516 may include aspects of site resource criteriaspace 12610 (FIG. 126). Resource criteria space may define values,ranges of values, types, ranges of types, and the like that may definegeneral required characteristics of the resources required by a clinicaltrial. Non-limiting examples of resource criteria include: maximumand/or minimum numbers of administrative personnel; maximum and/orminimum price points for subject drugs; a minimum and/or maximum numberof required patients to complete the trial; maximum and/or minimum pricepoints for equipment, to include equipment purchase and/or lease; and/orthe like.

Space definitions 12516 may include aspects of site resource space 12612(FIG. 126). Site resource space 12612 may include the set of parametersand values of the parameters that define different options andvariations of resources available at a particular site and/or group ofsites for implementation of clinical trials. Non-limiting examples ofsite resource space may include: expected drug and/or price points;expected access to drugs and/or equipment; expected patient recruitment,expected patient dropout rate; geographical locations; patientdemographics; expected availability of administrative and/or medicalpersonnel; and/or the like. The site resource space may include allpossible permutations of the parameters. For example, one site selectionmay be configured with different expected drug costs and differentadministrative personnel availabilities. The site resource space mayinclude all the permutations of all the parameters associated with theresources available at individual sites and/or site selections. The siteresource space may include millions of possible site selectionvariations. A resource optimization platform may evaluate allpermutations of parameters of the site resource space. A resourceoptimization platform may evaluate a partial set of permutations ofparameters of the site resource space. The partial set of permutationsmay be defined by a user. The partial set of permutations may beautomatically defined, such as according to the resource criteriaparameters.

Space definitions 12516 may include aspects of site selection resourcescenario space 12614 (FIG. 126). Resource scenario space may include theset of parameters and values of the parameters that define differentoptions and variations of scenarios associated with site selections andresource availability. Resource scenario space may define the parametersof the environment associated with one or more sites. Non-limitingexamples of resource selection scenario space include: expected flowthrough drug and/or equipment supply chains; expected weatherconditions, expected pandemics; expected economic conditions; and/or thelike. The resource scenario space may include all possible permutationsof the parameters. For example, one scenario may be configured with arange of values for average drug costs and a range of values for averageweather conditions, e.g., how will varying weather conditions affect theprice point and/or availability of a drug. The resource scenario spacemay include all the permutations of all the parameters associated withscenarios. The resource scenario space may include millions of possiblescenario variations. A resource optimization platform may evaluate allpermutations of parameters of the resource scenario space. A resourceoptimization platform may evaluate a partial set of permutations ofparameters of the resource scenario space. The partial set ofpermutations may be defined by a user. The partial set of permutationsmay be automatically or semi-automatically defined, such as according tothe resource criteria parameters.

Space definitions 12516 may include aspects of site resource performancespace 12616 (FIG. 126). Site resource performance space may include theset of parameters and values of the parameters that define theevaluation criteria for a site selection with respect to resourceavailability. Parameters may include: net present value (NPV), expectedNPV, incremental NPV, study cost, incremental study cost, study budget,incremental study budget, time to complete, incremental time tocomplete, time to market, incremental time to market, clinical utility,incremental clinical utility, probability of regulatory acceptance,incremental probability of regulatory acceptance, probability ofsuccess, incremental probability of success, statistical power,incremental statistical power, number of patients, incremental number ofpatients, number of sites, incremental number of sites, studycomplexity, incremental study complexity, operational complexity,incremental operational complexity, dose selected, incremental doseselected, statistical design, incremental statistical design, peakrevenue, revenue at year five (5), other revenue numbers, incrementalrevenue, market introduction, whether market introduction beatscompetition entry, number of treatment arms, hypothesissuperiority/equivalence/non-inferiority, other choices aroundstatistical design, treatment effect, hazard ratio, and other choicesaround estimating the characteristics of the patient population,response, and safety profile, screening criteria, dropout rate, andother choices around modeling/estimating the characteristics andbehaviors of the patient population and other factors that impact howthe study evolves and its likelihood of achieving its goals (howslowly/quickly patients enroll, etc.), site payments and other choicesaround operational aspects of the study that can impact how the studyevolves and its likelihood of achieving its goals, cost per patient,cost per site, or other cost factors, selections made in other projects(across users within customer companies or organizations and across allusers of the platform), priorities set by the customer company ororganization, and/or other user-defined filters based on availableinputs and outputs of the platform or in the systems and methodsdescribed herein. In embodiments, any of the parameters and variablesdescribed herein may be incremental parameters and variables. Siteselections may be evaluated and compared against all of the parametersof the performance space or a subset of the parameters of theperformance space. A set of site selections, e.g., one or more groupseach including one or more possible sites, may be evaluated for one ormore of the performance parameters.

The configuration facility 12506 may include a combinations component12518. The combinations component 12518 may automatically orsemi-automatically define the resource criteria design and/or resourcescenario space that may be evaluated by the platform 12504.

The simulation facility 12510 of the platform 12504 may, based on thespace definitions from the configuration facility 12506, evaluate thesite selections. The simulation facility 12510 may include models 12526.As used herein with respect to site selection, a model includes thecombination of parameters and the values that describe a site selectionand/or corresponding clinical trial designs and the scenario under whichthe site selection is evaluated with respect to resource availability.Models 12526 may include hundreds or even thousands of models. Models12526 may include deviation specifications for one or more of theparameters of the models. A deviation specification may define a rangeof values, a distribution of values, and/or a function of values for oneor more parameters of a model. The deviation specifications may be basedon expected or previously measured distributions or variations inclinical trial design parameters, site selection parameters, and/orresource availability parameters.

The simulation facility 12510 may include engines 12528. As used herein,engines may relate to the codification of a site selection and/orcorresponding resource availabilities that can receive model parametersand run a simulation to generate an output. The output of the engines12528 may be a predicted behavior, e.g., resource availability, for asite selection for one or more corresponding clinical trial designs, oneor more scenarios, and/or conditions. Engines 12528 may evaluate a siteselection with analytical methods, mathematical methods, numericalmethods, simulation, and/or the like. Evaluating a site selection mayinclude a simulation run to determine performance of the site selection.Evaluating a site selection may include using a Monte Carlo approach tosimulate a site selection for different values according to thedeviation specifications and using statistical methods to determine theperformance of the site selection from a simulation run.

The simulation facility 12510 may include search/exploration component12530. The search/exploration component may facilitate modification ofmodel parameters for simulation. The search/exploration component 12530may adaptively modify or generate models for simulations based onsimulation results of other models/site selections and/or based ontriggers and data from other facilities of the platform 12504.

The analysis facility 12508 may be configured to analyze simulationresults of site selections. The analysis facility 12508 may include afiltering component 12520. The filtering component 12520 may beconfigured to use one or more numerical and/or analytical methods toevaluate and compare the performance of evaluated site selections. Thefiltering component may identify optimal or near-optimal site selectionsfor one or more performance parameters. The filtering component maysearch the performance space and identify a set of optimal and/or nearoptimal site selections for one or more performance parameters, e.g.,availability of resources.

The analysis facility 12508 may include a recommendation component12522. The recommendation component 12522 may provide site selectionrecommendations. The site selection recommendations may be based onoptimal or near-optimal site selections determined by the filteringcomponent 12520. Recommendations may be adaptive based on settings,feedback, selections, triggers, and the like from the user, and/or otherfacilities in the platform 12504.

The analysis facility 12508 may include an augmenting component, 12524.The augmenting component may supplement simulation results withreal-world data.

The interfaces facility 12512 may be configured to providevisualizations and interfaces for comparing, searching, and evaluatingsimulated site selections. Visualization component 12532 may provide forone or more interfaces to visualize the performance of site selectionsand facilitate comparison of site selections by a user. The feedbackanalysis component 12534 may track user actions associated with theinterfaces and visualizations to determine patterns and/or preferencesfor site selections. The tradeoff advisor component 12536 may analyzeand provide data and guidance for evaluating tradeoffs between two moresite selections.

The platform 12504 may include and/or provide access to one or more datafacilities 12538. Data in the data facilities may include designhistories 12540, simulation data 12542, site data 12544, resource data12546, population data 12548, and the like.

FIG. 126 shows aspects of an embodiment of a process for site selection.The process may include four or more stages. Facilities of the platform12504 may be configured to implement the stages of the process. Thestages of the process may include a configure stage 12602. The configurestage 12602 may define one or more of the spaces associated with thesite selection. The configure stage 12602 may define one or more of siteselection criteria space 12610, site selection design space 12612, siteselection scenario space 12614, and/or site selection performance space12616. The configure stage 12602 may utilize one or more advisors,wizards, algorithms, and the like for defining the spaces. In someembodiments, the different spaces associated with the configurationstage 12602 may be defined by different members of a team based on theexpertise of the members. In some cases, members of a team may havedifferent specializations. For example, some members may specialize inscenarios, while others may specialize in site selection and/or designdefinitions. Separating the inputs may allow different team members toindependently optimize and improve specific models without affectingother inputs. In some embodiments, the inputs may be separated into twoor more types based on convenience, expertise, flexibility, and thelike.

The stages of the process may include an evaluate stage 12604. Theevaluate stage 12604 may configure models 12618 for evaluation usingsimulation 12620 and analytical methods 12624. The stage may includevarious methods of enhancing computation and simulation usingparallelization and resource management 12622.

The stages of the process may include an augment stage 12606. Theaugment stage 12606 may add real-world data to the simulation data.Financial data 12626, regulatory data 12628, revenue data 12630, and thelike may be added to the and used to augment data from simulations.

The stages of the process may include an explore and analyze stage12608. The explore and analyze stage 12608 may include filtering methodsand algorithms 12632 for identifying optimal site selections. The stagemay include generating and interacting with visualizations 12634 andtradeoff analysis tools 12636 to compare and select site selections.

In embodiments, the platform 12504 (FIG. 125) may be configured foridentification and confirmation of optimal site selections for aclinical trial. Optimality of site selection may be in relation to siteresource criteria, e.g., a parameter within site resource criteria space12610 (FIGS. 126 and 127). For example, embodiments of the currentdisclosure may provide for the determination of a site selection for aclinical trial as being the least likely site selection to experience adrug shortage during the duration of the clinical trial. Site resourcecriteria may be determined in relation to the site resource performancespace 12614 (FIGS. 126 and 127). Optimality of the site resourcecriteria, via site selection, may be in relation to one or more siteresource performance parameters, e.g., a parameter within site resourceperformance space 12616, and the values thereof. An optimal siteselection may be a site selection that achieves a most desirable valuefor one or more specific site resource performance parameters. A mostdesirable value may depend on the site resource performance parameterand may be different for each site resource performance parameter. Insome cases, the most desirable value may be the highest value of a siteresource performance parameter. In some cases, the most desirable valuemay be the lowest value of a site resource performance parameter. Insome cases, the most desirable value may be a range of values, aspecific value, a function of values, and the like. For example, in somecases an optimal site selection with respect to a drug availability siteresource performance parameter may be a site selection that has thelowest risk of drug supply interruption and achieves the goals of theclinical trial. As another example, an optimal site selection withrespect to an equipment resource performance parameter may be a siteselection wherein all sites within the selection haveduplicate/redundant equipment, e.g., multiple Magnetic Resonance Imaging(MIR) systems on site.

In embodiments, an optimum site selection is a site selection thatachieves most desirable values for two or more specific site resourceperformance parameters. In the case of optimality for multiple siteresource performance parameters, optimality may require a tradeoffbetween the parameter values. For example, a site selection that has alower risk of drug supply interruption may have a low NPV and thereforemay not be desirable. The optimality of a site selection may be based ona function of site resource performance parameters. In some cases, afunction may be a weighted sum of the site resource performanceparameters. A function, or a set of functions, may be used to generatean overall score (or a set of scores) and the score may be used todetermine the optimality of the site selection. A highest score, aspecific score, lowest score, and the like may be considered optimaldepending on the function used to compute the score.

In embodiments, optimality may be evaluated according to Paretooptimality. Pareto optimal site selections may be site selections whereno individual site resource performance parameter can be better offwithout making at least one other individual site resource performanceparameter worse off. In some cases, optimality may be determined usingconvex hull analysis.

In some cases, one site selection may be globally optimum. In somecases, more than one site selection may be globally optimum. In somecases, no site selections may be globally optimum. In some embodiments,optimality of site selection may be relative to a benchmark. A knownsite selection, a set of historical site selections, and/or the like maybe used as a benchmark. Site selections may be considered optimal ifthey meet, exceed, and/or are within a threshold distance of thebenchmark site resource performance parameters.

Site resource performance parameters that may be used to determine siteselection optimality may be user defined, system defined,algorithmically defined, and/or the like. In some cases, users mayspecify a subset of site resource performance parameters that should beused to identify optimal site selections. A user may define optimalitycriteria by defining ranges, values, characteristics, and the like ofthe parameter values that may be considered desirable and/or optimal.Interactive graphical interfaces may be provided to a user to evaluatedifferent site selections based on one or more optimality criteria.Interactive interfaces may allow a user to explore different siteselections by changing scoring methods, weights associated with thecriteria, and the like.

In embodiments, the characteristics of site resource performanceparameters for evaluated site selections may be analyzed by the platformto determine if any of the parameters may be less important foroptimality. For example, analysis may include evaluation of ranges,variability, and other statistical analysis. If one or more siteresource performance parameters for all evaluated site selections iswithin a desirable range, or the site resource performance parameter isalmost equal for all of the evaluated site selections, the site resourceperformance parameter may be removed and identified as less significantfor optimality and, in some cases, may not be factored in whendetermining optimality. Prior to determining optimality based on siteresource performance parameters, the site resource performanceparameters and the values of the site resource performance parametersmay be grouped, filtered, normalized, and the like.

Optimality of site selections may be redefined automatically,semi-automatically, in response to user input, and/or the like. Thecriteria for optimality of site selections may change as site selectionsare evaluated by the platform. For example, initial optimality criteriamay produce no optimal site selections. In response to no optimal siteselections being determined, the criteria may be changed (relaxed,increased, decreased, etc.) until at least one site selection isconsidered optimal. In another example, optimality criteria may changein response to user feedback. Users may evaluate initial site selectionsfound to be optimal and provide feedback (direct feedback and/orindirect feedback that can be derived from user actions and inactions).The feedback from the user may be used to change how optimality isdetermined, which site resource performance parameters are used todetermine optimality, the values of the site resource performanceparameters that are considered optimal, and/or the like.

In some embodiments, site resource performance parameters may begrouped, ordered, and/or organized into one or more hierarchies, groups,and/or sets. Two or more different optimality criteria may be used inparallel to determine multiple sets of optimal site selections underdifferent criteria. Two or more different optimality criteria may beused sequentially to determine optimal site selections. One criteria mayfirst be used to identify a first set of optimal site selections underfirst criteria. A second set of criteria may then be used on the firstset to reduce the set of optimal site selections.

In embodiments, a site selection may be globally optimum if the siteselection is optimal with respect to all possible site selectionoptions. In embodiments, a site selection may be globally optimum if thesite selection is optimal with respect to possible site selectionoptions for one or more criteria. In embodiments, a site selection maybe globally optimum if the site selection is optimal with respect to alarge percentage (such as 80% or more) of possible site selectionoptions for one or more criteria. In embodiments, a site selection maybe globally optimum if the optimality of the site selection is within ahigh confidence level (90% confidence) with respect to possible siteselection options for one or more criteria.

Traditional methods for evaluating site selections cannot determineglobal optimum site selections since they evaluate one, several, or asmall subset of site selection options. Traditional methods do notconsider all or almost all of the site selection options and cannot finda global optimum.

Trial site selection may involve numerous variables, parameters,considerations, tradeoffs, and the like resulting in a very large numberof possible variations. A large number of possible variations makesstudy site selections and optimization using traditional methodsdifficult. In many cases, traditional methods may fail to explore orconsider the complete space of possible site selection options and maymiss or never consider globally optimal site selections. Usingtraditional methods, the number of site selection variations that may beexplored in a reasonable time is limited. In some cases, only one (1)statistical site selection and only three (3) clinical scenarios may beevaluated. The best site selection study of the limited number ofvariations may not result in a globally optimal site selection. Alocally optimum site selection chosen from a limited number ofconsidered site selections may represent one (1) local maximum but maybe far from the globally optimum site selection. When 10,000 or moreclinical scenarios are considered, a globally optimum site selection maybe distinguished from the many locally optimum site selections. However,consideration of 10,000 clinical scenarios cannot be practicallyperformed using traditional methods as it would require an estimated50,000 hours or more to complete.

In embodiments, the platform and methods described herein may evaluatethousands or even millions of site selection options enabling adetermination of a global optimum site selection with respect toavailability of resources for a clinical trial. In many cases, theglobally optimum site selection may have significant advantages overlocally optimum site selection. In one example, a globally optimum siteselection may require less time to complete than other site selections.

In embodiments optimization of trial site selections for resourceavailability may occur sequentially after optimization of trial design.In one embodiment, a globally optimum trial design may be determinedusing the techniques described herein. After the globally optimum trialdesign is determined a globally optimum trial site selection forresource availability may be determined for the determined trial.

Referring again to FIG. 125, the platform 12504 may receive and/ordetermine performance space using the configuration facility 12506.Performance space may be defined in the space definitions component12516. The performance space may be configured based on input from usersand/or based on data 12538 such as history data 12540 and/or simulationdata 12542. In embodiments, data 12538 may include external data fromexternal data sources and providers. In one instance, performance spacemay define optimality criteria. Optimality criteria may define siteresource performance parameters, performance values, functions, methods,and algorithms for evaluating optimality and/or global optimality ofsite selections. In one instance optimality criteria may be configuredby the user or determined from benchmark site selections from history12540 and/or simulation 12542 data. In another instance, optimalitycriteria may be defined from simulation data from the simulationfacility 12510. Optimality of site selections may be determined in theanalysis facility 12508. The filtering component 12520 may be used todetermine one or more sets of globally optimum site selections from thesite selections evaluated by the simulation facility 12510.

FIG. 127 shows aspects of an apparatus/optimality analysis component12702 for determining global optimality of site selections with respectto availability of resources for a clinical trial. In embodiments, theoptimality analysis component 12702 may be part of the analysis facility12508 of the platform 12504. The optimality analysis component 12702 mayreceive data from simulated site selections 12712 and determine one ormore sets of optimal site selections 12722, 12724. The optimalityanalysis component 12702 may include one or more circuits fordetermining optimality of site selection. In embodiments, the optimalityanalysis component 12702 may include circuits for determining optimalitybased on optimality functions 12728. Optimality functions 12728 maydetermine optimality of site selections based on different weighting ofperformance factors of the simulated site selections. In embodiments,the optimality analysis circuit 12702 may include circuits fordetermining optimality based on benchmark analysis 12704. A benchmarkanalysis circuit 12704 may determine optimality of site selections basedon a comparison of site resource performance parameter values to one ormore benchmark site selections such as from historical data 12714 and/orsimulation data 12712. In embodiments, the optimality analysis circuit12702 may include circuits for determining optimality using sequentialanalysis 12708 and/or parallel analysis 12710. The sequential analysiscircuit 12708 and parallel analysis circuit 12710 may use one or moredifferent optimality functions 12728 in parallel or sequentially todetermine optimal site selections. In embodiments, the optimalityanalysis circuit 12702 may include circuits for dynamically modifyingoptimality criteria 12706. User inputs 12720, simulation data 12712,and/or the determined sets of optimal site selections may be monitoredand analyzed to determine modifications to optimality criteria. Inembodiments, the optimality analysis circuit 12702 identifies aconfidence level 12726 associated with the optimality of sets of optimalsite selections. In the case where simulation data 12712 may not includesimulations of all site selection options for the criteria space 12610,the optimality circuit 12702 may determine, based on the simulated siteselections, a confidence level that the determined optimal siteselections are indeed optimal for a given optimality criteria.

FIG. 128 shows aspects of an apparatus 12800 for determining globaloptimality of site selections with respect to availability of resourcesfor a clinical trial. In embodiments, the apparatus 12800 may include anoptimality analysis circuit 12814 which may be part of the analysisfacility 12508 of the platform 12504 (FIG. 125). In embodiments, theapparatus 12800 may include a data processing circuit 12806 structuredto interpret/obtain site resource data 12802 of a clinical trial siteselection. In some embodiments the site resource data 12802 may beoutputs of simulation data of trial site selections. The data processingcircuit 12806 may transform the site resource data 12802 into a formatsuitable for use by the various circuits in the apparatus. For example,the site resource data 12802 may be received by the data processingcircuit 12806, which may then determine and identify site resourceperformance parameters in the data. In some embodiments, some siteresource performance parameters may be grouped, filtered, converted,normalized, and the like.

The apparatus 12800 of FIG. 128 may further include an optimalitydetermining circuit 12808 structured to receive processed site resourcedata from the data processing circuit 12806. The optimality determiningcircuit 12808 may identify globally optimum site selections 12812 basedon one or more optimality criteria. In some embodiments, the globallyoptimum site selections 12812 may be provided as an output of theapparatus 12800. In some embodiments, globally optimum site selections12812 may be further processed by the site resource analysis circuit12810. The site resource analysis circuit 12810 may analyze the globallyoptimum site selections 12812, determine characteristics of the siteselections, and receive feedback data 12804 about the site selections.The site resource analysis circuit may, based on the determinedcharacteristics, determine modifications for optimality criteria used inthe optimality determining circuit 12808. Using modified optimalitycriteria, the optimality determining circuit 12808 may determine a newset of globally optimum site selections 12812.

As shown in FIG. 129, a method 12900 for determining globally optimumsite selections with respect to availability of resources for a clinicaltrial may include simulating all site selection options for a siteresource criteria 12902. The method 12900 may further includedetermining an optimality criteria for evaluating simulated siteselections 12904. Optimality criteria may be a function of one or moreperformance values for each site selection such as a weighted sum of thevalues, a comparison of the values, and the like. The method 12900 mayinclude searching for globally optimum site selection(s) in thesimulated site selections using the determined optimality criteria12906. The globally optimum site selections may be recommended to one ormore users 12908.

As shown in FIG. 130, a method 13000 for determining site selections toglobally optimize available resources for a clinical trial may includesimulating site selection options for a site resource criteria 13002.The method 13000 may further include determining a first optimalitycriteria for evaluating simulated site selections 13004. The method13000 may further include determining a second optimality criteria forevaluating simulated site selections 13006. The method 13000 may includedetermining a first set of optimum site selections using the firstoptimality criteria, the first set may be determined from the simulatedsite selections 13008. The method 13000 may further include determininga second set of optimum site selections using the second optimalitycriteria, the second set may be determined from the first set of siteselections 13010. The globally optimum site selections may berecommended to one or more users 13012.

As shown in FIG. 131, a method 13100 for determining a site selection toglobally optimize available resources for a clinical trial may includesimulating site selection options for a site resource criteria 13102.The method 13100 may further include determining a first optimalitycriteria for evaluating simulated site selections 13104. The method13100 may include determining a first set of optimum site selectionsusing the first optimality criteria, the first set may be determinedfrom the simulated site selections 13006. The method 13100 may furtherinclude identifying characteristics of site selections in the first setof globally optimum site selections 13108. The method 13100 may furtherinclude determining a second optimality criteria for evaluatingsimulated site selections based on the identified characteristics 13110.The method 13100 may include determining a second set of globallyoptimum site selections using the second optimality criteria from thesimulated site selections 13112.

Illustrated in FIG. 132 is a method 13200 for determining a siteselection to globally optimize available resources for a clinical trial,in accordance with an embodiment of the current disclosure. The method13200 includes determining a plurality of possible sites for recruitingpatients from for a clinical trial 13210. The method 13200 furtherincludes determining, for each of one or more subgroupings of theplurality of possible sites, a predicted available resources value13212. The method 13200 further includes determining which subgroupingof the plurality of possible sites has a predicted available resourcesvalue that globally optimizes a desired site resource criteria 13214. Inembodiments, determining the predicted available resources value foreach of the subgroupings of the plurality of possible sites includessimulating each of the subgroupings 13216. In embodiments, simulatingeach of the one or more subgroupings may be based at least in part onuse of different types of engines, e.g., engines with different versionnumbers and/or developed by different entities, e.g., in-house vsthird-party vendor. In embodiments, the differences in types of enginesmay include underlying types of algorithms and/or assumptions, e.g.,rounding rules. In embodiments, the method 13200 may further includedetermining one or more site resource parameters 13218. In suchembodiments, simulating each of the one or more subgroupings 13216 maybe based at least in part on the one or more site resource parameters.In embodiments, the one or more site resource parameters may be based atleast in part on: a supply of a drug; administrative personnel; and/orequipment. In embodiments, the method 13200 may further includedetermining the desired site resource criteria 13220. In suchembodiments, simulating each of the one or more subgroupings 13216 maybe based at least in part on the determined site resource criteria. Inembodiments, the determined site resource criteria may be based at leastin part on: a supply of a drug; administrative personnel; and/orequipment. In embodiments, determining which subgrouping of theplurality of possible sites has a predicted available resources valuethat globally optimizes the desired site resource criteria 13214 mayinclude and/or be based at least in part on: a convex hull engine; aPareto engine; a Monte Carlo engine; and/or a simulated annealingengine. In embodiments, determining which subgrouping of the pluralityof possible sites has a predicted available resources value thatglobally optimizes the desired site resource criteria 13214 may be basedat least in part on a machine learning engine, as described herein. Forexample, in embodiments, a neural network may be trained to look at pastsite selections and their outcomes and predict one or more site resourcecriteria. In embodiments, the neural network may be trained viasupervised learning and/or by unsupervised learning, e.g., cost-basedpolicies.

Turning to FIG. 133, an apparatus 13300 for determining a site selectionto globally optimize available resources for a clinical trial, inaccordance with an embodiment of the current disclosure, is shown. Theapparatus 13300 may form part of the platform 12504 or it may bestand-alone from the platform 12504 and/or communicate with the platform12504 via one or more application programming interfaces (APIs). Theapparatus 13300 includes a site selection data processing circuit 13310structured to interpret possible site selection data 13312 identifying aplurality of possible sites for recruiting patients from for a clinicaltrial. The apparatus 13300 further includes an available resourcesdetermination circuit 13314 structured to determine a predictedavailable resource value 13316 for each of one or more subgroupings ofthe plurality of possible sites. The apparatus 13300 further includes asite searching circuit 13318 structured to determine which subgrouping13320 of the plurality of possible sites has a predicted availableresources value that globally optimizes a desired site resource criteria13330. The apparatus 13300 further includes a site selectionprovisioning circuit 13322 structured to transmit the subgrouping 13320of the plurality of possible sites that has the predicted availableresources value that globally optimizes the desired site resourcecriteria. In embodiments, the available resources determination circuit13314 is further structured to determine the predicted availableresources value for each of the one or more subgroupings of theplurality of possible sites by simulating each of the subgroupings. Inembodiments, simulating each of the one or more subgroupings is based atleast in part on use of different types of engines, as described herein.In embodiments, the apparatus 13300 may include a user input circuit13324 structured to interpret user input data 13326 and a criteriadetermining circuit 13328 structured to determine the desired siteresource criteria 13330 based at least in part on the user input data13326. In embodiments, the site searching circuit 13318 may include aconvex hull engine; a Pareto engine; a Monte Carlo engine; and/or asimulated annealing engine.

Referring to FIG. 134, embodiments of the current disclosure may providefor a design platform 13400 with an interface 13410 for configuring andmanaging the platform 12504 with respect to optimizing site selectionfor availability of resources for a clinical trial. The design platform13400 may provide for pre-simulation determination of one or moreresource selection parameters, e.g., values within resource criteriaspace 12610, site resource space 12612, resource scenario space 12614and/or site resource performance space 12616. Some embodiments mayprovide for adjustment of resource selection parameters during asimulation. The interface 13410 may include a canvas area 13412 forvisualizing/editing/creating resource selection parameters for use bythe platform 12504 (FIG. 125). Embodiments of the interface 13410 may bea graphical user interface (GUI) that has one or more input fields 13414for inputting or selecting resource selection parameters. The inputfields 13414 may be sliders, text boxes, moveable components, and/orother GUI user input widgets. The graphical user interface may alsoprovide for a heat map for selecting possible sites. The heat map mayprovide for filtering of the possible sites. In embodiments, theplatform 13400 may provide, via servers 12554 (FIG. 125) multipleinterfaces, e.g., interfaces 13410, 13416, 13418, for collaborativeconfiguration of the platform 12504 by one or more users. Inembodiments, the interfaces 13410, 13416, 13418 may be configureddifferently for different users, e.g., an interface may be tailored to atype of user and/or target audience, e.g., clinical trial experts,novices, and/or other types of users of varying skill levels in clinicaltrial designs and/or site selection. Tailoring of an interface to a usertype may include enabling and/or disabling certain features and/oroptions on the interface. In embodiments, collaboration between usersmay involve a first user operating on a first interface 13410 receivinginputs from a second interface 13416 operated by a second user. Inembodiments, the interface 13410 may provide for weighting of one ormore resource selection parameters. In embodiments, the interface 13410may provide for configuration of the simulation component 12510 (FIG.125). For example, a user operating the interface 13410 may configurethe simulation component 12510 to perform an exhaustive search and/orsimulation of site selection options. In embodiments, a user operatingthe interface 13410 may configure the simulation component 12510 toperform a non-exhaustive search and/or simulation of site selectionoptions. In embodiments, the interface 13410 may provide for a user toconfigure the platform 12504 to user one or more of a convex hullengine, a Pareto engine, a Monte Carlo engine, and/or simulatedannealing engine. In embodiments, the interface 13410 may provide for auser to configure a training set for a machine learning engine to learnhow to optimize site selections with respect to resource availability,as disclosed herein.

Turning to FIG. 135, a method 13500 for collaborative configuration of asite selection platform 12504 for optimization of availability ofresources for a clinical trial is shown. The method 13500 includesdisplaying a graphical user interface structured to configure a systemfor determining which subgrouping, of a plurality of possible sites fora clinical trial, globally optimizes available clinical trial resources13510. The method 13500 further includes receiving, via the graphicaluser interface, one or more user inputs that define one or more resourceselection parameters used by the system 13512. The method 13500 furtherincludes storing the defined resource selection parameters in a memorydevice 13514.

Shown in FIG. 136 is an apparatus 13600 for providing collaborativeconfiguration of a site selection platform 12504 for optimization ofavailability of resources for a clinical trial is shown. The apparatus13600 includes a display generation circuit 13610 structured to generatea graphical user interface 13612 for configuring a system 12504 fordetermining which subgrouping, of a plurality of possible sites for aclinical trial, globally optimizes available clinical trial resources.The apparatus 13600 further includes a display transmission circuit13614 structured to transmit the graphical user interface 13612 to anelectronic device for display, e.g., 12502. The apparatus 13600 furtherincludes a user interaction circuit 13616 structured to interpret userinputs 13618 received by the graphical user interface 13612; and inresponse to, and based at least in part on, interpreting the user inputs13618, define resource selection parameters 13620 used by the system12504. The selection parameter provisioning circuit 13622 is structuredto store the defined selection-parameters 13620 in a memory device,e.g., 12538.

Shown in FIG. 137 is another method 13700 for collaborativeconfiguration of a site selection platform 12504 for optimization ofavailability of resources for a clinical trial. The method 13700includes configuring, via a graphical user interface, a recruitment siteselection system via entering one or more user inputs into the graphicaluser interface that define one or more selection-parameters 13710. Themethod 13700 further includes determining, via the recruitment siteselection system, which subgrouping, of a plurality of possible sitesfor recruiting patients from for a clinical trial, globally optimizesavailable clinical trial resources 13712. The method 13700 furtherincludes transmitting data identifying the determined subgrouping 13714.

Referring to FIG. 138, embodiments of the disclosure may provide for aplatform/system 13800 with an interface 13810, e.g., a wizard, forguiding a user through configuring a site grouping/selectionsystem/platform 12504 (FIG. 125) for optimizing site selection withrespect to availability of resources for a clinical trial. Inembodiments, the interface 13810 may be generated by a server 12554(FIG. 125). The interface 13810 may be command line based or graphicaluser interfaced based. The interface 13810 may generate a plurality ofprompts 13812 that assist in obtaining initial resource selectionparameters, e.g., criteria, from users to determine parameters forresource criteria space 12610, site resource space 12612, resourcescenario space 12614, and/or site resource performance space 12616. Theplurality of prompts 13812 may ask for a variety of static inputs orranges. The inputs may include the type of engine 12528 to use in thesimulation 12510. The inputs may also include the type of searchalgorithm 12530 used. The inputs may include the type of sensitivityanalysis algorithms or tools that are preferred. The inputs may includethe type of clinical trial. The interface may recommend one or more sitegroupings/selections based on the type of clinical trial. Therecommended site groupings/selections may serve as a starting base forfurther modification by a user. Artificial intelligence/machine learningapproaches may be used to generate the prompts 13812 and/or suggestionsfor the user through the configuration process. As will be appreciated,the suggestions and/or guiding by the interface 13800 may allow a userto avoid (or reduce) spending time and resources (including computingresources and the costs of those resources) on sub-optimal simulations.

In an embodiment, a method for guiding a user through configuring a sitegrouping/selection system/platform for optimizing site selection forresource availability for a clinical trial is provided. The methodincludes generating an interactive interface. The method furtherincludes presenting, via the interactive interface, a plurality ofprompts to a user structured to configure a site selection system 12504for determining which subgrouping, of a plurality of possible sites forrecruiting patients from for a clinical trial, globally optimizes adesired resource criteria, e.g., one or more parameters within resourcecriteria space 12610. The method further includes for each of theplurality of prompts, receiving a responsive user input, and configuringthe site selection system based at least in part on the responsive userinputs.

In another embodiment, a system for guiding a user through configuring asite grouping/selection system/platform for optimizing site selectionfor resource availability for a clinical trial is provided. The systemincludes a server structured to determine which subgrouping of aplurality of possible sites for recruiting patients from for a clinicaltrial globally optimizes a desired resource criteria. The system furtherincludes an electronic device, e.g., 12502, structured to: display aninteractive interface that presents a plurality of prompts to a user forconfiguring the server; for each of the plurality of prompts, receive aresponsive user input; and configure the server based at least in parton the responsive user inputs.

In another embodiment, a non-transitory computer readable medium storinginstructions is provided. The stored instructions, when loaded into atleast one processor, adapt the at least one processor to: generate aninteractive interface; and present, via the interactive interface, aplurality of prompts to a user. The plurality of prompts are structuredto configure a site selection system for determining which subgrouping,of a plurality of possible sites for recruiting patients from for aclinical trial, globally optimizes a desired resource criteria. Thestored instructions further adapt the at least one processor to, forreach of the plurality of prompts, receive a responsive user input; andconfigure the site selection system based at least in part on theresponsive user inputs.

Embodiments of the current disclosure may provide for prediction of aninitial site grouping/selection with respect to resource availability ofa clinical trial. In embodiments, the initial site selection may bestructured to maximize (globally optimize) access to clinical trialresources and/or other criteria, e.g., one or more parameters withinresource criteria space 12610, site resource space 12612, resourcescenario space 12614, and/or site resource performance space 12616. Forexample, in embodiments, a predicted initial site selection maycorrespond to minimizing interruptions in supply of a drug used in theclinical trial. In other embodiments, the predicted initial siteselection may correspond to maximizing the number of administrativepersonnel or healthcare providers available to conduct the clinicaltrial. In yet other embodiments, the predicted initial site selectionmay correspond to maximizing the availability of medical equipment usedin the clinical trial.

In embodiments, the initial site selection may be based at least in parton historical data. The historical data may include data from previouslyconducted clinical trials and/or it may include data from priorsimulated clinical trials. In embodiments, the data may be stored indata facility 12538 and/or be generated by the simulation component12510 and/or the analysis components 12508.

The prediction may be generated prior to receiving user input or afterreceiving some user input e.g., via user device 12502. The predictedinitial site grouping/selection may be displayed in a graphical userinterface, e.g., interface component 12512, for adjustment by a user.The predicted initial site grouping/selection may be thegrouping/selection actually used in the clinical trial, or it may serveas a starting point which the user can configure/tweak as desired. Thepredicted initial site grouping/selection may be the global optimal,with respect to the desired resource; or it may be close to the globaloptimal, wherein a user can tweak, i.e., make adjustments, it to be theglobal optimal. The initial prediction may reduce the amount of time tofind the global optimum by providing the user (or computer) with a goodstarting point based on knowledge gained from historical data. Simulatedannealing, e.g., via the search/exploration modules/engines 12530, maybe applied to the initial prediction to test the surroundingsubgroupings. Artificial intelligence may be used to analyze thehistorical data based on known desired criteria for the clinical trial.For example, in embodiments, a neural network may be trained onhistorical data to identify patterns in site selections that result inparticular values for the availability of a resource at one or moresites. The neural network may then process site selection data, i.e.,data regarding possible sites for a clinical trial, and then generate apredicted initial site selection.

Accordingly, referring to FIG. 139, a method 13900 for prediction of aninitial site grouping/selection for optimizing resource availability fora clinical trial is shown. The method 13900 includes accessing pasttrial site selection data stored in a database 13910. The method 13900further includes predicting, based at least in part on the past trialsite selection data, the initial site selection 13912. In embodiments,predicting the initial site selection may be based at least in part onartificial intelligence, as disclosed herein. The initial site selectioncorresponds to a global optimization of access to a desired resource forthe clinical trial, as disclosed herein. The method 13900 furtherincludes evaluating the initial site selection with respect to being theglobal optimization 13914. Such evaluation may be based at least in parton a convex hull engine, a Pareto engine, a Monte Carlo engine, or asimulated annealing engine, as disclosed herein. The method 13900 mayfurther include displaying the initial site selection in a graphicaluser interface 13916. In embodiments, the desired resource may be basedat least in part on a drug supply, administrative personnel, and/orequipment. In embodiments, the method 13900 further includes adjustingthe initial site selection via the graphical user interface 13918. Inembodiments, the method 13900 may further include interpreting one ormore user inputs, wherein the prediction of the initial site selectionis based at least in part on the one or more user inputs 13920. Inembodiments, the method may further include simulating the initial siteselection to determine performance criteria 13922. In embodiments, themethod 13900 may further include conducting a sensitivity analysis ofthe initial site selection 13924, e.g., via analysis component 12508.

Illustrated in FIG. 140 is an apparatus 14000 for prediction of aninitial site grouping/selection for optimizing resource availability fora clinical trial. The apparatus 14000 includes a past trial dataprocessing circuit 14010 structured to interpret past trial siteselection data 14012. The apparatus 14000 further includes a resourceprediction circuit 14014 structured to generate, based at least in parton the past trial site selection data 14012, initial site selection data14016 for a clinical trial. The initial site selection data 14016 maycorrespond to a global optimization of access to one or more resourcesfor the clinical trial. The apparatus 14000 further includes a resourceevaluation circuit 14018 structured to evaluate the initial siteselection data 14016 with respect to the global optimization. Theapparatus 14000 further includes a prediction provisioning circuit 14020structured to transmit the initial site selection data 14016.

Embodiments of the current disclosure may also provide for a method forusing the initial site selection. The method may include receiving aninitial site selection for a clinical trial, and conducting a clinicaltrial based as least in part on the initial site selection. The initialsite selection may correspond to a global optimization of access to oneor more resources for the clinical trial, wherein the initial siteselection was predicted from past trial site selection data. Forexample, a first entity may generate initial site selection data andsend it to a second entity that conducts a clinical trial based at leaston part on the initial site selection data.

Referring now to FIG. 141, embodiments of the current disclosure mayprovide for a platform/system 14100 that generates an interactiveinterface 14110, e.g., a GUI, for exploration/evaluation of spacesrelated to availability of resources for a clinical trial, as opposed tomerely facilitating selection of proposed sites, for the purpose ofglobally optimizing site selection for a clinical trial to optimizeavailability of resources. The spaces may include site resource criteriaspace 12610, site resource space 12612, resource site scenario space12614, and/or site resource performance space 12616. In embodiments,generation of the site selections and/or evaluation of the spaces may bebased at least in part on convex hull, Pareto frontiers, Monte Carlo,simulated annealing, and/or machine learning, e.g., artificialintelligence, as described herein.

Exploration/evaluation of the spaces may provide insights to a userregarding known and/or unknown constraints on site selection and/or theimpact a particular selection parameter, e.g., a parameter within one ofthe spaces, may have on resource availability.

Exploration of the spaces may be facilitated via visualizations of thespaces. The visualizations may include, and/or be based at least in parton, heatmaps and/or tornado graphs. The interface 14110 may include acanvas area 14112 for rendering (or rasterizing) the visualizations.

The interface 14110 may provide for users to adjust one or moreselection parameters and/or adjust sites within one or more proposedsite selections/groupings and see the effect on the predicted resourceavailability. Adjustment of the selection parameters may be facilitatedby one or more interactive widgets 14114, e.g., text boxes, buttons,sliders, and/or the like. In embodiments, adjustment of the selectionparameters may be facilitated via the canvas 14112. In embodiments, theinterface 14110 may allow users to evaluate and compare possible siteselections/groupings side-by-side.

In embodiments, exploration of the spaces may provide for sensitivityanalysis. For example, embodiments of the interface 14110 mayincorporate simulated annealing engines, as described herein.

In embodiments, platform/system 14100 may include a server, e.g. server12554 in the computation resources 12550 of platform 12504. The server12554 may generate the interface 14110 as a web application, remotedesktop, and/or other suitable architecture for providing the interface14110 to users and/or user devices 12502.

The platform 14100 may support collaboration among different users. Forexample, the server 12554 may generate multiple interfaces 14110, 14116,and 14118. In embodiments, the interfaces 14110, 14116, and 14118 may beconfigured/tailored to different types of user/target audience, e.g.,users with different levels of experience and/or knowledge with respectto evaluating site groupings/selection for various criteria. Forexample, a first interface 14110 for an expert user may have morefunctionality, e.g., access to more options and/or features, than asecond interface 14116 for a novice user.

Turning to FIG. 142, a method 14200 for exploring/evaluating spacesrelated to resource availability for a clinical trial is shown. Themethod 14200 includes generating a graphical user interface structuredto provide for interactive exploration of one or more spacescorresponding to one or more selection parameters for determining whichsubgrouping, of a plurality of possible sites for recruiting patientsfrom for a clinical trial, globally optimizes clinical trial resources14210. The method 14200 further includes adjusting at least one of theselection parameters via the graphical user interface 14212. The method14200 further includes updating the graphical user interface in responseto adjusting the at least one selection parameter 14214. In embodiments,the clinical trial resources may be based at least in part on a supplyof a drug, administrative personnel, and/or equipment. In embodiments,generating the graphical user interface occurs prior to simulating, asdisclosed herein, any one of the possible sites. In embodiments,generating the graphical user interface occurs after simulation of oneor more of the possible sites.

Illustrated in FIG. 143 is a non-limiting embodiment of an apparatus14300 for exploring/evaluating spaces related to patient recruitment fora clinical trial. The apparatus 14300 includes a resource spaceprocessing circuit 14310 structured interpret space data 14312corresponding to one or more spaces, e.g., 12610, 12612, 12614, and/or12616, related to subgroupings of possible sites for use in conducting aclinical trial. The apparatus 14300 further includes a graphics circuit14314 structured to generate interactive interface data 14316 inresponse to the space data 14312. In embodiments, the interactiveinterface data 14316 corresponds to a computerized interface 14110 forglobally optimizing site selection for clinical trial resourceavailability. The apparatus 14300 further includes a user input circuit14318 structured to receive user input data 14320 responsive to thepresentation of the interactive interface data 14316. The apparatus14300 further includes a resource space exploration circuit 14322structured to modify the interactive interface data 14326 in response tothe user input data 14320. The apparatus 14300 further includes aninteractive provisioning 14324 circuit structured to transmit themodified interactive interface data 14326.

Referring to FIG. 144, a method 14400 for updating site selectionaccording to available resources is shown. Since recommendation ofglobally optimal site selection, as disclosed herein, are generallypredictive, it is possible that one or more parameters used to determinea globally optimum site selection for a clinical trial may deviate fromwhat actually occurs during conduction/execution of the trial, i.e.,while the trial is underway. A globally optimum site selection may havebeen determined based on an initial availability of resources, when, inactuality, a global pandemic emerges shortly after the start of aclinical trial affecting the availability of resources. In such a case,the original globally optimum site selection may no longer be theoptimum. Updating of a site selection, as described herein, may occurmultiple times through the course/duration of the clinical trial. Insome embodiments, updating of the site selection, as described herein,may be performed on a continuous basis throughout the duration of theclinical trial.

Accordingly, the method 14400 includes obtaining a first simulationoutput for a first set of site selections for a clinical trial based onthe availability of resources 14410. The first simulation outputincludes first resource availability, as disclosed herein, associatedwith each site in the first set of site selections. The method 14400further includes determining a first resource availability 14412. Themethod 14400 further includes determining, within the first set of siteselections, a first globally optimum site selection based at least inpart on the availability of resources 14414. Optimum site selections maybe determined using one or more of Pareto analysis, convex hullanalysis, and/or simulated annealing analysis. The site selection maythen be configured based at least in part on the first globally optimumsite selection, e.g., the site selection may be made to conform to theglobally optimum site selection.

As further shown in FIG. 144, the method 14400 may includeconducting/executing the clinical trial based at least in part on thefirst globally optimum site selection 14416. Conduction of the clinicaltrial may be defined by a start/beginning 14418 of the clinical trialand a stop/end 14420 of the clinical trial. In embodiments, the start14418 may be the occurrence of the first patient recruitment. Inembodiments, the start 14418 may be the occurrence of the firstinteraction between administrative personnel (for the clinical trial)and a patient or recruitment site, in respect of the trial. Inembodiments, the start 14418 may be the first occurrence of a patientreceiving a treatment (including receiving a drug). In embodiments, thestop 14420 may be the last occurrence of patient receiving a treatment(including receiving a drug). In embodiments, the stop 14420 may be theoccurrence of the last interaction between administrative personnel (forthe clinical trial) and a patient or recruitment site, in respect of thetrial. The time between the start 14418 and the stop 14420 mayconstitute the duration of the clinical trial as that term is userherein. In embodiments, conduction of the clinical trial may includecommencement of any portion and/or process of the clinical trial whetherperformed in succession and/or intermittently.

After the start 14418 of the clinical trial, but before the stop 14420,the globally optimum site selection may be reassessed in view of changesto availability of resources. As such, the method 14400 includesobtaining, during conduction of the clinical trial, a second simulationoutput for a second set of site selections for the clinical trial basedon a second resource availability 14422. The second simulation outputincludes second site selection performance parameters associated witheach design in the second set of site selections for a second set ofsite selection criteria. In embodiments, the second simulation outputmay be different than the first simulation output. For example, thesecond simulation output may be from another evaluation of the siteselections according to a second resource availability. In embodiments,the second simulation output may be the same as the first simulationoutput. For example, the first simulation output may be reused. Inembodiments, the second site selection performance parameters may bedifferent than the first site selection performance parameters. Forexample, the second site selection performance parameters may includemore or fewer parameters than the first site selection performanceparameters. In embodiments, the second site selection performanceparameters may be the same as the first site selection performanceparameters. In embodiments, the second set of site selections may be thesame or different than the first set of site selections. For example,the second set of site selections may include additional sitesselections and/or have removed site selections as compared to the firstset of site selections. In embodiments, the second set of site selectioncriteria may be the same or different than the first set of siteselection criteria. For example, availability of a resource such as adrug for the clinical trial and/or site selections may have changedsince the start 14418.

The method 14400 further includes determining, within the second set ofsite selections, a second globally optimum site selection 14426.Determination of the second globally optimum site selection may be basedat least in part on the second resource availability 1424. The method14400 may further include adjusting the site selection based at least inpart on the second globally optimum site selection 14428. Adjustment ofthe site selection may include conforming the site selection to thesecond globally optimum site selection.

Illustrated in FIG. 145 is another method 14500 for updating siteselections based on resource availability. In particular, method 14500identifies a globally optimum site selection for a clinical trial for afirst resource availability after the start 14512 of the clinical trial,but before the end 14514 of the clinical trial, where an initialglobally optimum site selection may not have been determined, or was notdetermined by an entity performing method 14500. Accordingly, the method14500 includes obtaining, during conduction of the clinical trial 12416,a simulation output for a set of site selections for the clinical trialfor a resource availability 14518. The simulation output includes siteselection performance parameters associated with each site selection inthe set of site selections for a resource availability. The method 14500further includes determining, from the set of site selection criteria, asite selection optimality criteria for evaluating the first set of siteselections 14520. The method 14500 further includes determining, withinthe set of site selections, a globally optimum site selection based atleast in part on the site selection optimality criteria and theavailability of resources 14522. The method 14500 may further includerecommending the globally optimum site selection for the availableresources 14524. Recommendation may include transmitting the globallyoptimum site selections to an entity performing and/or planning theclinical trial. The recommended globally optimum site selections may bethe first time a globally optimum site selection wascalculated/determined for the clinical trial, or the globally optimumsite selection may be an update to a previously calculated/determinedglobally optimum site selection. In embodiments, the method 14500 maynot include recommending the globally optimum site selection, but rathermay include adjusting the site selection based at least in part on theglobally optimum site selection 14526. It is to be understood, however,that embodiments of the method 14500 may not include adjusting the siteselection trial based at least in part on the globally optimum siteselection. In embodiments, the method 14500 may include bothrecommending and adjusting the site selection based at least in part onthe globally optimum site selection.

FIG. 146 shows aspects of another view or organization of a platform14606 as discussed herein. In one embodiment, entities such as users mayinteract with the platform 14606 with a user device such as anapplication in a browser 14604. The browser application 14604 mayreceive content from a content management system 14602. The browserapplication 14604 may communicate with an authentication module 14610 toauthenticate the entity and enable access to the services 14618 andother elements of the platform 14606. In embodiments, the access andinteraction with the platform 14606 may include interaction with theapplication programming interface 14612 of the platform 14606. The APIinterface 14612 may provide an interface to the services 14618 of theplatform. The services of the platform may provide services provided bythe configuration facility 106, analysis facility 108, simulationfacility 110, and/or the interfaces facility 112 shown with respect tothe platform configuration of FIG. 1. The services of the platform 14606may include services such as an engine registry service 14624, queryservice 14626, subscription service 14628, simulation service 14630,project service 14632, statistical service 14634, and augmentationservice 14636.

In embodiments, one or more of the services may interact with otherservices and interact with the compute component 14638. The computecomponent 14638 may include components for executing simulations. Thecompute component may include one or more components that provide thefunctionality of the simulation facility 110 of the configuration of theplatform shown in FIG. 1. The compute component 14638 may include queues14640, 14642, 14644 that provide data to and/or receive data fromengines 14650. The queues may sort and manage simulation models forsimulation by the simulation engines 14650. Data from the queues and/orengines 14650 may be stored and received by the data storage and datamanagement components such as a data lake 14651, storage service 14646,and databases 14648.

In embodiments, the platform 14606 may include one or more cloudservices 14616 provided by one or more cloud providers. Cloud servicesmay include code management services 14652, deployment pipeline services14654, container services 14656, and the like. In embodiments, one ormore monitors 14620 may monitor the operation of the platform 14606 andidentify errors, faulty components, completions of operations orprocessing and the like. The monitors 14620 may cause alerts or othernotifications for the browser app 14604. In some embodiments, theplatform 14606 may include an application insights 14622 module whichmay provide performance monitoring and management of applications andcomponents associated with the platform 14606.

In embodiments, elements of the platform may include a quantum computer.In embodiments, one or more algorithms and/or methods described hereinmay be implemented using a quantum computer that may be executing aquantum algorithm. A quantum computer may be a computer that is based onquantum mechanical phenomena such as superposition and entanglement toperform operations on data. A computing system may include a hybridsystem that includes a quantum computer and a classical computer. Themethods and systems described herein may be deployed such that they aredistributed among the classical and quantum computers. A quantumcomputer may execute one or more quantum algorithms for solving one ormore quantum computing tasks, and a classical computer may execute oneor more classical algorithms for solving one or more classical computingtasks. In embodiments, parts of the platform may use quantum computingand quantum algorithms to speed up computations for algorithms or partsof algorithms that are difficult for classical computers. In someembodiments, algorithms for quantum search, quantum simulation, quantumannealing, and the like may be used in parts of the platform forimplementing aspects of the methods and systems described herein.

In embodiments, one or more algorithms and/or methods described hereinmay be implemented with artificial intelligence algorithms such asmachine learning algorithms and neural network algorithms Artificialintelligence algorithms may be used to build mathematical models basedon training data to make predictions or decisions. In embodiments,training data may include any one or subset of: interface interactions,simulated annealing inputs and results, pareto analysis inputs andresults, convex hull analysis inputs and results, recommendationalgorithm inputs and results, orchestrating algorithm inputs andresults, design advisor inputs and trade-off advisor inputs and outputs,and other data received or determined by the platform described herein.In embodiments artificial intelligence may include supervised machinelearning, unsupervised machine learning, reinforcement machine learning,and the like. In embodiments artificial intelligence algorithms may beused to identify design optimality, identify optimal designs, identifyanalysis flow and methods to reduce computation and analysis time, andthe like.

In embodiments, the system and methods described herein may be includeone or more computing resources such as a cloud computing service. Thecloud computing service may provide on demand availability of computersystem resources. Computing and/or storage resources may be allocatedbased on demand, cost, timing requirements, and the like. The computingresources may be distributed across multiple locations. Computingresources may be allocated on demand during operation of the platform.Different stages of operation may require different computing resources.Simulations, for example, may require an increase in computing andstorage resources. The amount, locations, and the like of the computingresources may be selected based on timing and cost considerations. Highpriority design studies may be allocated more resources for example. Inembodiments, cloud computing may be used for platform and functions tooptimize trial design, site selection, and/or clinical trial resources.

In embodiments, the system and methods described herein may utilize oneor more external data sources. External data sources may includedatabases of data, federated data sources, government data, real-timedata, and the like. In some cases, external data sources may be queriedfor data from a single source. In some cases, external data may requiredata harvesting from multiple locations or resources using one or morecrawlers, queries, bots, and the like. For example, financial data usedfor augmenting data in the platform described herein may requirequerying or multiple resources to determine current costs for sites,doctors, drugs, and the like. External data sources may be updated usingdata calculated, compiled, or determined by the platform or parts of theplatform. Data may be written to multiple locations while using one ormore write-back methods to maintain data coherency.

In embodiments, the system and methods described herein may includeauthentication and/or provide conditional access. The platform,resources associated with the platform, and the like may requireestablishing and confirming identities of entities that interact withthe platform and associated resources thereof. Entities may be personsand/or other resources. Identities may be associated with account andmay track usage for billing and accounting. Identities may be associatedwith access or capabilities restrictions. Some aspects of the platformmay be enabled for some entities associate with specific accounts basedon subscription level. Conditional access may be provided to specificalgorithms, models, engines, data, analysis interfaces, and the like.Data and communications may be secured with one or more encryption anddata security methods for maintaining data security and confidentiality.

In embodiments, the system and methods described herein may includemetadata. Metadata may include descriptive metadata, structuralmetadata, administrative metadata, reference metadata, and/orstatistical metadata. Metadata may be associated with stored data, dataas it progresses through the platform, elements of the platform (forexample elements that may self-identify and register to the platform).Metadata may be associated with major data structures and elements ofthe system. Metadata may be associated with and/or accompany datarelated to the design space, criteria space, performance space and thelike. The metadata may provide information about where the dataoriginated, who or what created the data, when the data was created,assumptions and limitations of the data and the like. For example,simulated data may include metadata that relates to the engines andalgorithms that were used for the computations. The metadata mayidentify what version of engines, what random number seeds were used,known limitations and compatibility of the engines and data generated bythe engines with other engines and data produced by other engines.

In embodiments, the system and methods described herein may includereporting functionality. Reporting may include charts, spreadsheets andother tools used to present the results of the optimization processand/or the data fed into the optimization process. Reporting may includeheat maps and tornado graphs. Reporting may be generated for user reviewand analysis. In some cases reporting may be generated for machineanalysis. User report and machine reports may include differentformatting and amounts of data. Reporting may be system initiated oruser initiated. In some cases reporting may be triggered by an event,such as in an analysis. Reporting may include data and documentation foraudit or methods, procedures, and the like used by the platform andparts thereof. Reporting may be necessary for compliance and regulatoryapproval.

In embodiments, the system and methods described herein includeintegrations with one or more databases, third party systems, sources ofdata, marketplaces, computational resources, and the like.

In embodiments, the systems, methods, and platform described herein mayinclude aspects of application programming interfaces (APIs). APIs mayinclude software interfaces that provide for communications betweenvarious components of the overarching clinical trial framework, e.g.,backend servers, frontend graphical user interfaces, querying ofhistorical data, available resource data, and the like. APIs may beexposed (such as software hooks) for expanding, controlling, and/ormodifying functionality of the platform. APIs may include libraries andframeworks for interacting and integrating third party simulation andanalysis systems. Third party simulation engines may consume platformAPIs to control or use system resources. In embodiments, the systems,methods, and platform described herein may consume APIs of external orinternal software and systems.

In embodiments, the system and methods described herein may includealerts. The platform or components thereof may include components forgeneration and transmission of data messages to an end user (human ormachine). Alerts may be generated for notifying an end user of analysisresults, status of processes (such as simulation, analysis,configuration, and the like), errors (delays in processing,unavailability of platform or external resources, unauthorized access,and the like), time of completions of simulations and/or analysis, andthe like. Alerts may be logged for system audit and used forpredictions. Alerts may be pushed or pulled to user devices, such asmobile devices and may wake a device from a sleep or low power mode.Alerts may be provided to other platform elements which may be used as atrigger to initiate and/or abort other processes of the platform. Forexample, simulated annealing analysis may provide alerts when improveddesigns are observed. The alerts may be provided to a user and used totrigger an update of interfaces that display analyzed designs.

In embodiments, the system and methods described herein may includecollaboration features. Collaboration may include collaboration amongusers. Components of the various interfaces may provide for users tocollaborate with respect to trial design and/or site selection.Collaboration may include: messaging/commenting systems, screen sharing,and/or platforms that merge various elements that are created/edited bydifferent users. Users may be able to post, view, edit and/or downloadsimulation results. Collaboration may include collaboration acrosssites. Users at different locations may use and collaborate with thesame system. Collaboration may include collaboration across time.Settings, analysis, results, and the like may be saved and modified bydifferent users at different times. Changing settings from analysisperformed in the past may automatically trigger analysis based on newsetting and a comparison against previous results.

In embodiments, the systems and methods described herein may includedesign and optimization or various clinical trial types and may include:parallel group design, cluster randomized design, crossover design,titration design, enrichment design, group sequential design,placebo-challenging design, blinder reader designs, single-stageup-and-down phase 1 design, two-stage up-and-down phase 1 design,continual reassessment method phase 1 design, optimal/flexiblemultiple-stage designs, randomized phase II designs, dose-escalatingdesign, biomarker-adaptive design, adaptive randomization design, pickthe winner design.

In embodiments, the system and methods described herein may includetrial design and optimization for different phases of trials. Inembodiments, different phases of trials (such as preclinical, phase 0,phase 1, phase 2, phase 3, phase 4) may use different considerationsand, in some cases, use different simulation engines, analysisalgorithms, interfaces, wizards, and the like. In embodiments, thescenario space, design space, criteria space, and/or performance spacemay be modified or different based on the phase of the trial and/or typeof trial.

In embodiments, the systems and methods described herein may includeconsideration and analysis of trial resources. Trial resources mayinclude resources to prepare, conduct, and evaluate a clinical trial.Examples include drugs/drug supply subject to the trial, devices subjectto the trial, and/or administrative personnel and/or equipment needed toadminister a procedure/drug/device subject to the trial. Resources mayinclude test equipment to analyze and certify results. Availability,cost, time for acquisition and the like of resources may be a factor inperformance space, design space, scenario space, and/or criteria spaceduring design and evaluation of clinical trials.

Computational resources (such as servers and cloud services) used forsimulation or analysis during trial design may operate in batch mode ormay operate with a time delay between when the resources are requestedand when they are available for use. Batch mode and a time delay mayreduce responsiveness of an interactive design simulation. Inembodiments, a platform may predict when a request for computationresources should be issued such that they are available when needed.Triggers, such as progress in the interface, time of day, amount of dataentered, meeting schedules, and the like may be used to predict whensimulations or analysis will be ready for execution or computation. Inembodiments, machine learning models may be used to predict whencomputational resources should be requested such that they are readywhen simulations are ready for execution. Models may use historicaldata. Computation resources may be requested ahead of time before theyare needed in anticipation of a future request.

In embodiments, the size of a batch of computation (which may becorrelated with the time of computation) may be sized based on predictedcomputational requirements for the project. Predictions may be based onhistory of similar projects, users, and the like. In embodiments, thesize of a batch may be related to when computation resources areexpected to be available, a prediction of when simulations or analysiswill be ready for execution or computation and how long the execution orcomputation is expected to take.

FIG. 147 shows aspects of an apparatus for determining resourceallocation in accordance with an embodiment of the current disclosure.The apparatus may include a resource allocation engine 14706. Theresource allocation engine 14706 may include a resource response datacomponent 14708 configured to identify and/or maintain data related toresource capabilities, costs, allocation delay, computing power and thelike. The resource response data component 14708 may include one or moretables or databases that identify available or authorized resources forperforming batch computations for simulation, analysis, and otherplatform tasks. The resource response data component 14708 may beconfigured to trigger the polling engine 14712 to determine data forcomputational resources. The polling engine 14712 may be configured toperiodically or upon a trigger event, identify a list of availableresources, their availability, cost, computational capability, time toavailability and the like. The polling engine 14712 may transmit a datarequest directly to one or more resources to determine theiravailability. In some cases, the polling engine 14712 may transmit adata request to a central database to determine data for the resources.The polling engine 14712 may update, with the resource response data,the component with the determined data. The resource allocation enginemay receive data related to the design progress 14702 within theplatform. The design progress may indicate what data has been enteredfor a design study, how quickly data is entered, what part of theinterface the user is currently interacting with, and the like. Theresource allocation engine may receive data related to the studyparameters 14704. The study parameters 14704 may identify how manydesigns and/or scenarios are being considered for simulation, types ofsimulations required, the types of computation engines related to thesimulations, and the like. The prediction engine 14710, may, based onthe design progress data 14702 and/or study parameter data 14704,predict when resources will be required and how much of the resourcesare required for the study. The prediction engine 14710, may, usingresource response data and the required resource predictions determinewhen the resources should be requested such that they are available whenneeded. The prediction engine 14710 may factor in the allocation delay,costs of resources, and the like to determine when a request forresources should be made and how many resources should be requested. Insome cases, the prediction engine 14710 may determine, based on thepredictions, a trigger in the design progress data 14702 that whenreached will cause the resource allocation engine to issue a resourcerequest 14714 to allocate resources in anticipation of need.

In embodiments, the prediction engine may determine when resourcesshould be allocated or determine progress triggers for allocation basedon historical data of design progress and time of resource request. Inembodiments, one or more machine learning models may be trained on thehistorical data to train the model to predict when resources will beneeded. The prediction when the resources will be needed may then beused to request resources ahead of when they are needed according to thetime delay associated with each resource. In some embodiments,additional data such as calendar data, meeting data, and the like may beused to make or supplement the prediction process. Meeting data mayindicate that resources may be required for computation during themeeting.

In embodiments a prediction engine may determine triggers such as aspecific location in the interface that indicate that the study isalmost ready for simulation and resources should be requested. Triggersmay include when specific data is entered, when one or more locations inthe interface progression are reached, and the like.

As shown in FIG. 148, a method for determining a trigger for requestingcomputational resources may include monitoring design specificationprogress 14802 and determining resource allocation parameters 14804.Resource allocation parameters may include data related to the timedelay between when a resource is requested and when the allocation isavailable for use. The method may further include predicting whencomputation resources will be required based on the design specificationprogress 14806. Predicting may be based on historical data, trainedmachine learning models, external data, and the like. Based on thepredicting, a design specification progress trigger point may bedetermined 14808. The trigger point may be identified to correspond tothe time delay associated with obtaining a resource and expectedrequirement of the resource. The design specification progress may bemonitored for the determined trigger and in response to the triggerbeing observed, the computational resources may be requested such thatthey are allocated and ready when they are predicted to be needed 14810.

In embodiments, computing resources may be allocated in anticipation ofcollaborative sessions for trial design. For example, embodiments of thecurrent disclosure may detect that one or more users are in, or areabout to enter, a collaborative session and spool computing resources.The spooling of computing resources may be based on one or more aspectsof the platforms, disclosed herein, that the users are likely to use. Inembodiments, where it is detected that one or more uses are about toenter a collaborative session with interactive interfaces, as describedherein, one or more computationally expensive but highly interactiveinterfaces may be spooled up to improve overall responsiveness of theinterfaces to the users.

In certain aspects, allocating of resources may be based on one or moretriggers, e.g., a user location in an interface, embodiments of theplatform may provide an alert and/or message dialogue box to a userconfirming that the user's wishes to proceed with the allocation.

Embodiments of the current disclosure may provide for a score forcomparing simulated designs. The score may be a proxy or an indicator ofmetrics that may not be directly determined from available or simulateddata. The score may be used as a guide to identify interesting orvaluable designs during design analysis or exploration. The score may beused as an initial design ranking score. As will be understood,embodiments of the analysis facility 108 (FIG. 1) may compute the score(herein also referred to as a “proxy score” or a “comparison score”).

The comparison score may be a score based on one or more scorecomponents. The score may be a function of one or more score components.Score components may include one or more simulated, predicted, and/orcalculated performance metrics of a design such as cost, time tocompletion, success, and the like. Score components may include one ormore elements of the design space such as properties of a design thatare not dependent on simulation and may be related to the type of adesign and/or specified by a user. For example, score components mayinclude aspects of design type, dose of drug, frequency of drug, maximumduration, patient inclusion/exclusion criteria, randomization type, andthe like.

The score may be computed based on a weighted sum or other function of aplurality of score components. Score components and/or functions for ascore may be configured by a user. A user may configure a score via oneor more interfaces or may provide a specification by other means (suchas via a specification or configuration file that is accessible by theplatform). A user (using an interface, specification files, etc.) mayspecify or select one or more score components for computing the score,the function used to compute the score, weighting of score components,normalization of score component values, and the like. In some cases, aset of preconfigured scores that have preconfigured score components,weights, functions, and the like may be selected from a list ofpredefined scores.

In some cases, score configuration may include an input or aspecification of the type of score the user would like to compute. Thetype may include that the score is a proxy score for NPV, duration,robustness, and the like. Each of the types may be associated with a setof score components. Based on the selection of type and the associatedscore components for each type, the platform may identify a list ofavailable score components that are related to a computation of the typeof score selected. In some cases, not all score components associatedwith the type of score selected may be available in the simulated data.The available score components for the selected score type may beautomatically used to compute the score. In some cases, the availablescore components may be presented to a user and the user selects one ormore of the score components for inclusion in the score.

In some cases, the score components may be normalized or transformedbefore the score component is used in the computation of a score. Scorecomponents may be normalized according to the type of data (i.e.Boolean, integer, float, string, etc.), number of possible values (i.e.a set of possible values, continuous values), range of values (i.e.difference between maximum and minimum values in the simulation data),and the like. For example, score components that are of a string datatype may be normalized to an integer value wherein each string isrepresented by a different integer value. In another example, scorecomponents that are of a string data type may be normalized to a valuebetween 0 and 1. In another example, score component values that arelarger than 1 or less than 0 may be normalized such that each scorecomponent value is within the range between 0 and 1. Normalization maybe configured such that the maximum value of a score component isnormalized to the value 1, the minimum value of a score component isnormalized to a value of 0, and all other values of the score componentare normalized to a value between 0 and 1 where the normalized value isbased on how far the value was from the maximum. For example, a scorecomponent x may be normalized to a score component x′ according tox′=(x−x_(min))/(x_(max)−x_(min)). In embodiments, normalization mayinclude normalization techniques that include and/or are based on linearscaling, clipping, log-scaling, z-score, and the like. In embodiments,normalization may include normalization techniques includingsubstitution, rounding, mapping, and the like. In some cases,normalization techniques that normalize each score component value to avalue between 0 and 1 may be preferable as they can be easier tomanipulate and compare numerically.

A score may be a function of one or more score component values. In oneembodiment, a score may be a sum of the values of a plurality of scorecomponents. In another embodiment, a score may be a sum of thenormalized values of a plurality of score components. In yet anotherembodiment, a score may be a weighted sum of the normalized values of aplurality of score components. For example, a score s₁ for a design maybe computed as a weighted sum of the normalized score components c₁, c₁,. . . , c_(n) according to s₁=w₁c₁+w₂c₁+ . . . +w_(n)c_(n) wherein w₁,w₁, . . . , w_(n) are weighting values associated with each normalizedscore component. The weights associated with each score component forthe computation of the score may be based on relative importance of thescore component. Score components that are more important for a scoremay be multiplied by a larger weighting value.

A score may be computed for each simulated design. In some cases aplurality of scores based on different score components, functions,weights, and the like may be computed for each simulated design. Thescore may be used to filter designs such that only designs that arelarger than the score, lower than the score, between some values, and/orthe like are shown. The score may be used to rank or order designs suchthat designs with the highest score are shown first to a user.

In embodiments, the score may be computed before simulation (a scorethat is not based on simulation results), during simulation (scores maybe computed using one or more simulated score components in real time assimulation results are obtained), and/or after simulation.

In embodiments, a score computed using normalized score component valuesmay be a relative score. The score may provide a relative value of adesign with respect to other designs that are computed according to thesame normalization. In some cases, scores may not be absolute and scoresfrom different simulation runs may not be comparable. For example, if ascore is normalized with respect to the minimum and maximum scorecomponent values of a simulation, the score will not be comparable witha score from a different simulation that has different minimum andmaximum score component values.

In some cases, score values may be stored or associated with the dataused to determine the score. A score may be associated or stored withdata that identifies which score components were used to compute thescore, the values of the score components, the function for computingthe score, the normalize score components, normalization function,and/or the like. The associated data may be a vector or array of datathat is stored or associated with each score or simulation run and maybe used to determine if scores from different simulation runs arecomparable. The associated score data from two different simulation runsfor different designs may be compared to determine if the scores arebased on the same score function, normalization function, scorecomponents, and the like to determine if they can be used to accuratelycompare designs from different simulations. In some cases, when thescores from different simulation runs are identified as not comparablebased on the comparison of the associated data, the mismatch between theassociated data may be identified. In some cases, the mismatch betweenthe data may be used to identify functions or methods to recalculate ormodify one or more of the scores to make the scores comparable.

For example, one set of scores for designs simulated in a firstsimulation run may be based on the same score function, scorecomponents, and normalization functions for the score component valuesas a second set of scores for designs in a second simulation run. Thefirst set of scores and the second of scores may still not be comparablesince the minimum and/or maximum values of the score components for thefirst simulation run and the second simulation may be different whichmay result in a different normalization of values (such as when thenormalization is based on the minimum and maximum values as describedherein). In one example, identification of the minimum and maximumvalues for the score components for each simulation run may allow amodification of the scores such that they are based on the minimum andmaximum scores of the two simulation runs. In embodiments, theassociated data for scores from two or more simulation runs may becompared. The platform may determine if the scores are comparable. Ifthey are not comparable the platform may determine if the associateddata includes enough information to transform or renormalize the scorecomponent values such that they are comparable.

FIG. 149 shows aspects of an apparatus for determining a score inaccordance with an embodiment of the current disclosure. The apparatusmay include a scoring engine component 14908. The scoring enginecomponent 14908 may be part of the analysis facility 108 of the platform104. The scoring engine component 14908 may determine a score for designthat may be used to compare the designs. The scoring engine component14908 may receive one or more simulation data 14902 that may includesimulated performance characteristics of designs and the designdefinitions. The scoring engine component 14908 may receive one or morescore selections 14904 that may define which score should be computed,how a score is computed, the type of score that is computed and thelike. The score selections 14904 may be defined by user input 14906 orother data input or files that are accessible to the scoring engine14908. The scoring engine component 14908 may include a scoringdefinitions component 14920 that provides definitions or mappingsbetween score selections 14904 and operations, score components, andcalculations that are needed to determine a score. The score definitions14920 may include data that defines what score components should beincluded for one or more score type calculations.

The scoring engine component 14908 may include a simulation dataanalysis component 14912 that may identify score components that areused for computing a score and may determine if and how they should benormalized. The simulation data analysis component 14912 may analyze therange of the data, data type, number of values, and the like to identifythe normalization operations for the score components. The normalizationcomponent 14910 may be configured to perform normalization operations onthe score component values from the simulation data according to theresults of the simulation data analysis 14912 component. Thenormalization component 14910 may perform any number of normalizationfunctions including, substitution, mapping, rounding, clipping, and thelike. The calculation module 14914 of the scoring engine 14908 maydetermine one or more scores of the designs according to the scoredefinition 14920 and normalized data from the normalization component14910. The score and associated data 14918 may be stored in a databasethat is local to the scoring engine 14908, in other parts of theplatform 104 or external to the platform. The score and associated data14918 may include the score, score definitions used to determine thescore, normalization functions used to normalize values of the scorecomponents, results of simulation data analysis (such as min and maxvalues), and/or the like.

The scoring engine component 14908 may further include a comparisoncomponent 14916. The comparison component 14916 may be configured toreceive score and associated data 14918 from one or more simulation runsand determine if the scores are comparable. Scores may be comparable ifthe scores are based on the same score definitions, calculations,normalization functions, and the like. The comparison component 14916may compare the scores and associated data from one or more simulationruns and determine if the scores may be modified to make themcomparable. In embodiments, the comparison component 14916 may identifydifferences in the associated data (such as differences in normalizationfunctions) and determine how one or more of the scores or scorecomponents may be modified or mapped to new values to make scorescomparable. In some cases, the comparison component 14916 may cause oneor more of the calculation components 14914, normalization components14910, and/or simulation data components 14912 to recalculate or modifythe score based on the determined differences in the associated databetween scores.

As shown in FIG. 150, a method for determining a score for a design mayinclude obtaining trial design simulation results for a set of trialdesigns 15002 and receiving a score selection 15004. The score selectionmay be a definition of a score, a type of a score, a framework of ascore (such as what weights and type information), and the like. Basedon the score selection, the score components for the score selection maybe identified 15006. The score components may be identified according tothe type of score that the user specified. A lookup table may be used toprovide a listing of all score components that are related to a scoretype. The identifying of step 15006 may include searching the simulationresults to find which score components are available. The method mayfurther include determining a normalization function for each scorecomponent 15008. The normalization function may be based on the type ofdata, ranges of data, and the like as described herein. Each scorecomponent may have different normalization functions. In some cases twoor more normalization functions may be applied to a score component. Thenormalization functions may be used to normalize the score components15010 and the normalized score components may be used to determine ascore 15012. The score may be based on a function of the scorecomponents. The function may be a weighted sum of the normalized scorecomponents. The weights may be specified by the user or determined basedon the type of score. Scored designs may be presented and/or recommendedto a user and ranked or filtered according to the score.

As shown in FIG. 151, a method for score transformation may includeobtaining design scores and associated score data for designs from aplurality of simulation runs 15102. The simulation runs may be fromparallel simulations or simulations at different times. The associatedscore data may include data as to how the score was computed,normalization functions, score functions, weighting of score components,aspects of the data values (such as ranges, min/max values, etc.) of thescore components, and the like. The method may include comparing theassociated score data to determine if the scores from the plurality ofsimulation runs are comparable 15104. If the associated score dataindicates that the scores are based on the same or comparable functions,normalization functions, and the like the scores may be determined ascomparable and otherwise determined as not comparable 15106. When thescores are not comparable, the method may include determining anormalization function for one or more scores to make the scorescomparable 15108. For example, the normalization function may be takeninto account the minimum and maximum values for score components acrossall of the simulation runs and determine a multiplications factor orother function to make the scores comparable. Designs with scores thatare comparable may be presented and/or recommended to a user and rankedor filtered according to the score. In embodiments, the proxy score maybe computed during one or more collaborative session for designanalysis. In such embodiments, the proxy score may be based at least inpart on one or more user preferences detected through one or moreinteractive interfaces. In embodiments, the proxy score may be generatedin part via machine learning, e.g., a neural network. For example, aneural network can be trained to generate a proxy score from one or moredesign parameters and/or scenario parameters.

In embodiments, the platform may be configured for collaboration.Collaboration features may be enabled via one or more methods and/orinterfaces for design specification, filtering, and selection.Collaboration features may be configured to allow multiple users to worktogether to determine, develop, analyze, and/or select a trial design.In some embodiments interfaces and methods may be configured such thatmultiple users may view and interact with design and analysis tools forgroup evaluation of simulated designs. Collaboration features may beused to facilitate collaboration between users at different locations(or simply users that use separate computers and interfaces) and/orusers that are at one location and can view the same interface.Collaboration may occur in one or more collaboration sessions.Collaboration sessions may include sessions where multiple users work ondifferent or the same tasks concurrently. Collaboration sessions mayinclude sessions where multiple users work and collaborate on differenttasks sequentially. Collaboration sessions may occur in a continuoustime block or may include two or more disjoint or asynchronous timeblocks that may occur at different times of the day, different days, andthe like.

In some embodiments, a collaboration session may include one or moreusers collaborating in real time. A real-time collaboration session mayinclude a session in which multiple users may work together to reach aconsensus on one or more aspects of a trial design. The real-timecollaboration session may include a session in which users may worktogether to evaluate and select one or more trial designs based onevaluation of simulated trial designs. The real-time collaborationsession may include a session in which users may work together tospecify design and evaluation parameters for a simulation for a trial.

During a collaboration session, the interface may step through one ormore tasks for accomplishing the goals of the session. Tasks may beassociated with a sequence of different graphical interfaces, a sequenceof computations, and/or a combination thereof. The sequences ofinterfaces and/or computations may be at least partially preconfiguredproviding for a framework of sequences for accomplishing a task. Theframework of sequences may include divergent or a tree like frameworkallowing users to tailor or dynamically change the sequences based ondecisions made during the session, results from previous operations, andthe like.

For example, in one case, a goal of a collaboration session may includeselection of one or more trial designs from a set of simulated trialdesigns. Based on the specified goal, a platform may load or determine aproposed starting point for the session (such as which interface toshow) and what interfaces may be shown and/or computations may beperformed as a result of selections or actions in the first interface.As an example, the starting point for the session in this example may bea list of top or optimum design as determined from the simulated datausing convex hull analysis. The interface may show the top designs alongwith their parameters. The top designs may be shown with options forselection, further analysis, comparison, and the like. Based on theselections the sequence may be configured to provide additional analysisor comparison of the top designs or provide additional suggested designs(such as twins or siblings of the top designs). The design may furtherbe compared against one another or against the space of all availabledesigns (such as using heatmaps, tornado diagrams, and the like). In oneexample, the general sequence for the session may include designselection, design comparison, evaluation of twin designs, a drill downof performance parameters, and the like. The sequence of interfaces maybe configured to ensure the top designs are considered, as well asalternative designs that are close to selected designs are consideredduring the session.

In another example, a sequence of interfaces and/or computations in asession may be configured to surface, in real time, similar designs suchas twins, siblings, Pareto designs, and the like to one or more selectedor top designs. A user or a group of users may be guided toexplore/consider a range of different design types and/or designparameters. Design alternatives (such as different design types,siblings, twins, etc. that may have similar performance to selecteddesigns) may be automatically identified (such as by using one or morePareto, Convex Hull, and other algorithms) and provided forconsideration. Parameters of the alternative design that complement ordiverge from previous designs and selections may be emphasized and usersmay be guided to make evaluations and selections of the alternativeparameters.

In another example, a sequence of interfaces and/or computations in asession may be configured to allow designs to be compared with respectto robustness of the designs. Robustness of the designs may indicate therange of parameters for which designs have acceptable or goodperformance. Interfaces may be used to indicate design performance overa range of parameters in addition to the best possible performancethereby allowing users to visualize/evaluate and debate the risksassociated with the designs.

In some embodiments, collaboration interfaces in a collaboration sessionmay be tailored or customized based on the type of the user. Users maybe provided with a different interface according to their expertise,authority, tasks, roles, and the like. During a collaboration session,the platform may receive or determine the type of user interacting withthe platform. A user type may be specified by an administrator or acurator of a project or a session. A user type may be associated with anidentity or credentials of a user. In some cases, a user may specifytheir own role or type. In some cases, the sequence of interfaces oravailable computations may be different for each user type in a session.For example, during a collaboration session configured with a goal ofselecting one or more designs, different user types may be showndifferent parameters of a design under consideration. The parameters anddata shown to the user may depend on the expertise of the user. Forexample, a user designated as a financial expert may be show parametersthat are focused on the cost, time, resources, personnel, and the likeassociated with the design. Another user that is designated as an expertin patient recruitment may be shown parameters of the designs that focuson the patient requirement and/or assumptions associated with eachdesign. In embodiments, each interface customized for each user type mayprovide options to search for other designs according to the parametersassociated with the user type. In some cases, some users may be providedwith interfaces that hide certain aspects, such as aspects that aresensitive or that the user is not authorized to view. In someembodiments, interfaces may be configured such that every group membercan view the same interface during a collaboration session.

In some embodiments, decisions in a collaboration session may beachieved by consensus, voting, and the like. In embodiments, some usersor user types may be designed as owners or curators of one or moreparameters of the designs. The owners or curators may be specifiedaccording to expertise of the user. In some embodiments, consensus on adesign decision may require approval by each curator of one or moreparameters of the design. In some cases, design parameters may bedivided into subsets and different users may be assigned as experts foreach subset of parameters. In one example, during a collaborationsession, different users may be shown different parameters of a designbased on their expertise. The interfaces for each user may show optionsfor approving a design based on the respective parameters, rejecting thedesign based on the respective parameters, and the like. In oneconfiguration, consensus on a design or a selection of a design during acollaborative session may require approval from each user responsiblefor a subset of the design parameters. In another example, interfacesfor voting on designs may allow a user to collectively agree or disagreeon a design by voting. In some cases, votes of users may be weightedbased on their expertise, seniority, and the like. In embodiments, theplatform may trac each user vote (a binary value such as yes or no, arange of values or rating such as 1-10, or 1-100). The votes may beassociated with the user expertise such that the votes may be filteredaccording to each expertise or type of user. The votes may be associatedwith a weight (based on seniority, expertise, assigned weight). A votescore for a design may be determined by summing all the votes and/orvote value for each design. In some embodiments, each vote or each votevalue may be multiplied by the weight associated with each vote todetermine a vote score.

In another example, a goal of a collaboration session may includeselection of one or more trial designs from a set of simulated trialdesigns. A collaboration session may be configured to divide users intomultiple groups of one or more users. Each group may be provided with asequence of interfaces and computations to evaluate and select one ormore designs. Each user or group of users may individually exploreand/or be guided to explore and consider different designs. Designselections made by the individuals or subgroups of users may then beevaluated collectively in a joint collaborative session.

In another example, a goal of a collaboration session may includedevelopment of simulation parameters for running a design simulation.Based on the specified goal, a platform may load or determine a proposedstarting point for the session (such as which interface to show) andwhat interfaces may be shown and/or computations may be performed as aresult of selections or actions in the first interface. As an example,the starting point for the session in this example may be an interfacefor specifying design goals and design parameters. The sequence ofinterfaces may step through the design, scenario, and performanceparameters that need to be defined before the simulation is executed. Inembodiments, different users may be identified as experts or associatedwith different parameter types. In some cases one type of users may beshown only parameters for scenarios while another may be shown onlyparameters for designs.

As shown in FIG. 152, a method for determining a collaborative sessionsequence may include receiving a goal for a collaboration session 15202.Based on the goal, a framework for a sequence of interfaces and/orcomputations for the collaboration session may be identified 15204. Themethod may further include determining the next sequence based userinput in the initial interface, according to the framework 15208.

As shown in FIG. 153, a method for generating a collaborative interfacemay include displaying a graphical user interface structured to evaluatedesigns by a group of users 15302. The method may further includeidentifying expertise parameters for each user in the group of users15304 and configuring the graphical user interface for each user basedat least in part on the expertise parameters 15306. The method mayfurther include receiving user input from users via the graphical userinterface 15308 and scoring designs based on the user input andexpertise parameters 15310.

FIG. 1154 shows aspects of an apparatus for generating a collaborativeinterface. The apparatus may include a collaborative interface circuit15408. The collaborative interface circuit 15408 may generate interfaces15416. The collaborative interface circuit 15408 may receive userinteraction 15402 from the interfaces 15416. The collaborative interfacecircuit 15408 may receive user type definitions 15404 that may be usedfor interface customization with the selection parameter provisioningcomponent 15410. The sequence of the interfaces may be defined by thesequence component 15412 according to the user interactions 15402 withthe user interfaces 15416 populated with simulation data 15406.

The space of simulated designs can be explored in a systematic way usingconvex hulls and convex hull peeling. As described herein, convex hullsseparate out P-designs that are reachable by linear weighting criteria(CH-designs or CH-points). In many cases, design analysis andrecommendation may start with recommendations of CH-designs or designsthat are twins, siblings, or are within an epsilon distance to theCH-designs. Designs that are on or near the convex hull are often themost desirable designs (designs that are often ultimately selected for astudy). Concentrating recommendations and design analysis on designs onor near the convex hull greatly reduces the number of designs that needto be examined. In some cases only one or two percent of the totalsimulated designs need to be considered when initial designrecommendations provided by the platform are on or near the convex hull.Design recommendations based on convex hull designs may have furtherbenefits such as providing fast evaluation for any weights specified andallowing introduction of constraints that can be used to eliminateunlikely or uninteresting designs and scenarios.

In embodiments, simulated designs may be explored based on a hierarchyof convex hulls. A hierarchy of convex hulls may be created bydetermining a convex hull of designs, removing the designs that are onthe convex hull, and determining another convex hull of the remainingdesigns. The “peeling” of convex hulls and determining new convex hullscan be performed iteratively to identify a series of convex hulls in asimulated design space. The designs associated with each convex hull cancreate a hierarchy of designs.

FIG. 155 shows a graphical example of a hierarchy of convex hulls. Thefigure shows four layers (CH_1, CH_2, CH_3, and CH_4) of convex hulls ina two dimensional example. The first convex hull (CH_1) of the designs(represented by points in the graph) may be determined by finding theconvex hull of all the designs. The second convex hull (CH_2) may bedetermined by finding the convex hull of all the design except thedesigns that are on CH_1. The third convex hull (CH_3) may be determinedby finding the convex hull of all the design except the designs that areon CH_1 and CH_2. The fourth convex hull (CH_4) may be determined byfinding the convex hull of all the design except the designs that are onCH_1, CH_2, and CH_3, and so on. In the example, the convex hulls arepeeled to identify a new convex hull of the remaining design to create ahierarchy of designs according to each convex hull layer. It should beunderstood that although FIG. 155 shows a convex hull peeling example intwo dimensions, a hierarchy of convex hulls may be determined for anynumber of dimensions for data related to any number of performanceparameters.

Designs from each convex hull may be associated with a level. Thedesigns in each convex hull may be stored and associated with the convexhull level on which they can be found. In general, designs on the firstconvex hull (first level) may have better performance than designs onfollowing convex hulls (higher levels). In some cases, although a designfrom a higher lever may have worse performance than a design in a firstlevel convex hull, the design from a higher level may be preferable fora study due to other considerations such as practicality, familiaritywith the design type, regulatory approval delays, and the like. Thehierarchy of designs may provide for quick identification of designsthat are within a given percentage of the optimum designs (designs thatare on the first convex hull). In some embodiments, convex hull levelsmay be used for recommending designs to a user (such as with therecommendation engine described herein). Initial recommendations mayinclude recommendations from the first convex hull or the first coupleof convex hulls. In response to a user request or other triggers,additional recommendations from other levels of convex hulls may beprovided to the user. The organization and progressive suggestion ofdesigns from higher level convex hulls provides for a systematicorganization of designs for recommendations allowing a user to considerdesigns ordered by their optimality.

In some embodiments convex hull levels may be associated with an epsilondistance. Convex hull peeling may include peeling of designs that are ona convex hull and designs that an epsilon distance from the designs onthe convex hull. Designs associated with each convex hull level mayinclude designs that are on a convex hull and designs that are epsilondistance away from the designs on a convex hull. Epsilon distance convexhulls level may be defined by first determining designs on the convexhull and epsilon distance designs from the designs on the convex hull.The designs on the first convex hull and epsilon distance away from thedesigns on the first convex hull may be associated with the first level.The second level designs may be determined by finding designs a convexhull of all the design except the designs that are in the first level.The second level designs may include designs that are on the secondconvex hull and all the designs that are epsilon distance away from thesecond convex hull. Additional levels of designs may be determined in alike manner. In embodiments, epsilon distance may be refined based onthe number of designs in each level. In some cases, a different epsilondistance may be defined for each level such that each level has the samenumber of designs, less than predetermined number of designs, at leastminimum number of designs, or other metric.

As shown in FIG. 156, a method for determining a design hierarchy basedon convex hull peeling may include obtaining trial design simulationresults for a set of trial designs 15602. The method may further includedetermining designs on a first convex hull of the set of trial designs15604. In some cases, the method may include identifying designs thatare epsilon distance from the designs on the first convex hull 15606 andthe designs epsilon distance away from the first convex hull may beidentified as first level designs 15608. In embodiments, the epsilondistance may be adjusted such that the number of designs that in thefirst level is within a range of values or is less than or more than athreshold value. To determine the second level of designs, the designsidentified as being in the first level may be removed from the set ofdesigns 15610 and a second convex hull of the remaining designs may bedetermined 15612. Optionally, designs that are an epsilon distance fromthe second convex hull may also be identified 15614. Designs on thesecond convex hull and the designs epsilon distance away from the secondconvex hull may be identified as second level designs 15616. Inembodiments, the epsilon distance may be adjusted such that the numberof designs in the second level is within a range of values or is lessthan or more than a threshold value. In some cases, the epsilon distancemay be adjusted such that the number of designs in the second level isthe same or within a threshold value to the number of designs in thefirst level. The process of “peeling” the convex hulls (and optionallydesigns that are epsilon distance away from the designs on the convexhull) and determining new a convex hull may repeat until a desirednumber of design levels is obtained. Designs in each level may bepresented and/or recommended to a user and ranked or filtered accordingto their associated level. The platform may use the hierarchy of convexhulls to suggest or identify the best designs (designs that are on thefirst convex hull) and second-best designs (designs that are on thesecond convex hull) and so on.

In some embodiments, a hierarchy of convex hulls and convex hull peelingmay be used to reduce the number of simulations in a study. In somecases where scenarios are monotone with respect to criteria, results ofsimulation of one scenario may be leveraged to reduce the number ofdesigns that need to be simulated to find the convex hull for designsfor other scenarios. In one embodiment, an algorithm may iterativelydetermine a convex hull of designs under a first scenario and simulatethe designs for a second scenario. The convex hull of the designs in thesecond scenario may be determined without simulating all of the designsbut only designs that are within the first couple of convex hulls underthe first scenario until no improvement to the convex hull of thedesigns under the second scenario is observed. In some examples, a 4×-8×reduction in simulations needed to find the convex hull for a secondscenario can be achieved by leveraging convex hull peeling in simulateddesigns for a first scenario.

FIGS. 157(a-e) shows a graphical example of how convex hull peeling maybe leveraged to reduce the number of simulations needed to find a convexhull for designs for a scenario. In embodiments, some scenarios may bemonotone with respect to criteria and can be ordered. In some cases,some scenarios parameters may be known to have a direct correlation toone or more performance parameters of designs. In cases where thescenarios may be ordered with respect to the performance of the designs,convex hulls of simulations for one scenario may be leveraged to reducethe number of simulations needed to find a convex hull for another(worse) scenario. In embodiments, simulations may be performed fordesigns under a first scenario. In some cases the simulations fordesigns under the first scenario may be exhaustive. Levels of convexhulls may be determined for the designs using convex hull peeling asdescribed herein. To determine designs that are on a convex hull for asecond scenario, only the designs that are on the convex hulls of thefirst scenario may be simulated.

FIGS. 157(a-e) shows a progression how convex hulls for designs for onescenario (scenario “67”) may be used to determine which designs shouldbe simulated for a second scenario (scenario “69”) to determine theconvex hull designs for the second scenario. It should be noted that thefigures, for clarity, do not show all of the simulated designs for thefirst scenario and only show the designs that are on the convex hull forthe first scenario. FIG. 157(a) shows the first iteration of the method.In the first iteration a first convex hull for designs for scenario 67may be determined (CH_67_1). The designs in the first convex hull maythen be simulated to determine their performance under the secondscenario (CH_67_1_69) and the convex hull of all the designs simulatedfor the second scenario may be determined (CH(CH_67_1_69)). After thefirst iteration, in this example, only designs that are on CH_67_1 aresimulated for the second scenario.

FIG. 157(b) shows the second iteration of the method. In the seconditeration, a second convex hull for designs for scenario 67 isdetermined (CH_67_2). The second convex hull may be determined by convexhull peeling described herein. The designs in the second convex hull maythen be simulated to determine their performance under the secondscenario (CH_67_2_69) and the convex hull of all the designs simulatedfor the second scenario may be determined (CH(CH_67_2_69)). In thesecond iteration, in this example, only the designs that are on CH_67_2are simulated for the second scenario. In the second iteration, for thisexample, the convex hull for the second scenario does not change.

FIG. 157(c) shows the third iteration of the method. In the thirditeration, a third convex hull for designs for scenario 67 is determined(CH_67_3). The third convex hull may be determined by convex hullpeeling described herein. The designs in the third convex hull may thenbe simulated to determine their performance under the second scenario(CH_67_3_69) and the convex hull of all the designs simulated for thesecond scenario may be determined (CH(CH_67_3_69)). In the thirditeration, in this example, only the designs that are on CH_67_3 aresimulated for the second scenario. In the third iteration, for thisexample, the convex hull for the second scenario changes compared to thesecond iterations.

FIG. 157(d) shows the fourth iteration of the method. In the fourthiteration, a fourth convex hull for designs for scenario 67 isdetermined (CH_67_4). The fourth convex hull may be determined by convexhull peeling described herein. The designs in the fourth convex hull maythen be simulated to determine their performance under the secondscenario (CH_67_4_69) and the convex hull of all the designs simulatedfor the second scenario may be determined (CH(CH_67_4_69)). In thefourth iteration, in this example, only the designs that are on CH_67_4are simulated for the second scenario. In the fourth iteration, for thisexample, the convex hull for the second scenario further changescompared to the second iterations.

The iterations of determining a new convex hull for the first scenario,simulating the designs from the convex hull under the second scenario,and determining the convex hull of all the simulated designs under thesecond scenario may continue until there is no improvement or change inthe convex hull for the second scenario for a threshold number ofiterations (such as two or more, or three or more iterations). FIG.157(e) shows the tenth iteration of the method. In the tenth iteration,a tenth convex hull for designs for scenario 67 is determined(CH_67_10). The tenth convex hull may be determined by convex hullpeeling described herein. The designs in the tenth convex hull may thenbe simulated to determine their performance under the second scenario(CH_67_10_69) and the convex hull of all the designs simulated for thesecond scenario may be determined (CH(CH_67_10_69)). In the tenthiteration, in this example, only the designs that are on CH_67_10 aresimulated for the second scenario. In the tenth iteration, for thisexample, the convex hull for the second scenario has not changed formore than two iterations and method may stop wherein the convex hulldesigns for the second scenario are defined by the convex hull of thedesigns simulated up to and including the tenth iterations(CH(CH_67_10_69)). For this example, the number of designs that requiredsimulation for determining the convex hull for the second scenariocorresponds to the number of designs on the first ten convex hulls forthe first scenario. The number of designs on the first ten convex hullsis a small percentage of the total number of designs for this example.In many embodiments, simulation for scenarios based on convex hullpeeling may results in a reduction of simulation of four to eight timescompared to an exhaustive simulation for a scenario.

A convex hull peeling for finding convex hull for adjacent monotonescenario without simulating full set of designs may take as input adataset for a first scenario. The dataset for the first scenario mayinclude simulation results for all design for the first scenario and mayinclude design parameters for the designs and a multicriteria vectorthat identifies the simulated performance of the designs for the firstscenario. Input to the algorithm may further include scenario variablesfor a second scenario. The algorithm may output the designs on theconvex hull for the second scenario. The algorithm may start byinitializing stopping parameter k to an initial value of 1. In step twoof the algorithm, the kth convex hull for the dataset for scenario 1 maybe computed using a convex hull algorithm. In step three of thealgorithm, each design in the kth convex hull determined in step two maybe simulated under the second scenario to calculate its multi-criteriavectors. In step four, the convex hull of the vectors determined in stepthree may be determined. In step five, the convex hull for the secondscenario is compared to the convex hull computed for the second scenarioin the k−1 iteration. In step six, the value of k may be incremented andsteps two through five of the algorithms may be repeated until theconvex hull for the second scenario does not change for at least twoiterations.

As shown in FIG. 158, a method for determining a convex hull for ascenario using convex hull peeling in another scenario may includeinitializing an iteration counter k to a value such as the value one15802. The method may include computing the kth convex hull for designssimulated for a first scenario 15804. The designs from the kth convexhull may be simulated for a second scenario 15806 and a convex hull forall the designs simulated for the second scenario may be computed 15808.The value of k may be incremented 15810 and the method repeated startingat 15804 until no improvement to the convex hull is observed for iiterations 15812 wherein i may be a variable set by a user and may havea value of two or more.

FIG. 159 shows aspects of an apparatus for convex hull peeling inaccordance with an embodiment of the current disclosure. The apparatusmay include a peeling engine component 15904. The peeling enginecomponent may receive simulation data 15902. The simulation set 15906component may store and manipulate the simulation data. The convex hullengine 15908 of the peeling engine may determine a convex hull of thesimulation data. The simulation set component 15906 remove designs thatare found in a convex hull from the simulation data and associate themwith design levels 15912. The epsilon engine 15910 may optionallydetermine designs that are epsilon distance away from the designs on theconvex hull. These designs may be optionally assigned to levels that areassociated with each convex hull.

In embodiments, convex hull peeling may provide for evaluation of adesign's robustness. For example, in embodiments, each convex hull levelcan have its own robustness ranking. In such embodiments, a user may beable to determine the most robust designs in each layer. As will beunderstood, in embodiments, some layers may have designs with an averagerobustness higher than an average robustness of other layers. Thus, someembodiments of the current disclosure may focus a user to search fordesigns within a particular layer having a high robustness. Embodimentsof the design recommendation algorithm, as described herein, mayevaluate the robustness of each layer and rank one or more of the layersbased at least in part on robustness. The recommendation algorithm maybe configured to recommend one or more layers, e.g., the top three (3),based on preferences derived from historical data, e.g., past userpreferences.

Turning to FIG. 160, embodiments of the current disclosure may providefor adaptive replication in clinical trial design simulations and/orother types of simulations described herein. As will be understood,embodiments of the simulation facility 110 (FIG. 1) may evaluate aclinical trial design by using a fixed number of simulated replications.Adaptive replication, however, may involve dynamically changing thenumber of simulation replications for a particular design. Inembodiments, adaptive rules may terminate replication sampling fordesigns. As will be explained in greater detail below, such changes maybe based on computed standard error or other performance criteria.

Accordingly, an embodiment system 16000 for providing adaptivereplication in clinical trial design simulation is shown. The system16000 may include a server 16010 having at least one processor and amemory device. The system 16000 may further include an electronic device16012, one or more remote servers 16014, 16016, 16018, and/or a database16020 which may be in electronic communication with the server 16010and/or each other via a network 16022. The server 16010 may form part ofand/or host one or more of the platforms 104 (FIG. 1), 10404 (FIG. 104)and/or 12504 (FIG. 125), e.g., the simulation facilities 110 (FIG. 1),10410 (FIG. 104) and/or 12510 (FIG. 125); and/or the computationalresources 150 (FIG. 1), 10450 (FIG. 104), and/or 12550 (FIG. 125).

The server 16010 may be structured to execute a replication processforming part of a clinical trial design simulation that comprises aplurality of replications of a clinical trial design. As will beunderstood, a replication of a clinical trial design is a simulatedinstance of a clinical trial design under a given scenario and with agiven set of parameters. During the replication process, the server16010 may determine a performance criteria, e.g., a member of criteriaspace 318 (FIG. 3) that defines a characteristic of the clinical trial,e.g., a number of patients who successfully completed the clinicaltrial. The server 16010 may then adjust the replication process based atleast in part on the performance criteria. The adjustment may increaseor decrease the number of replications of the clinical trial in thereplication process. For example, if the server 16010 determines thatthere is little variation in the performance criteria of the mostrecently executed replication as compared to one or more previouslyexecuted replications, the server may reduce the number, e.g., the totalnumber, of replications executed/evaluated in the replication process.As will be appreciated, reducing the number of replications in such amanner may reduce the overall time and resources required to completesimulation of the clinical trial design. Conversely, if the server 16010determines that there is variation (above a desired amount) in theperformance criteria of the most recently executed replication ascompared to one or more previously executed replications, the server16010 may increase the number of replications executed/evaluated in thereplication process. As will be appreciated, increasing the number ofreplications in such a manner may improve the accuracy of thesimulation. The server 16010 may also make other types of adjustments tothe replication process, as described herein.

The electronic device 16012 may be a user device, e.g., 102 (FIG. 1),such as a desktop, laptop, smart device, etc. In embodiments, theelectronic device 16012 may provide for and/or present an interactiveinterface, e.g., 112 (FIG. 1) that presents a plurality of prompts to auser for configuring the clinical trial design. The electronic device16012 may also receive and display the results of the clinical trialsimulation and/or provide notifications to a user regarding anyadjustments made to the replication process by the server.

The database 16020 may form part of a data facility, e.g., 138 (FIG. 1)and store replication results data, e.g., data generated duringexecution/evaluation of a replication of a clinical trial design. Inembodiments, the database 16020 may store the replication results in aquick search data structure, as described herein, e.g., a SimCube. Assuch, embodiments of the server 16010 may access the database toretrieve and/or store replication results data.

The remote servers 16014, 16016, and/or 16018 may form part of acollection of computation resources, e.g., 150 (FIG. 1) which can beaccessed by the server 16010 to distribute processing tasks. Forexample, the server may generate batches of replications of the samereplication process and/or of entire clinical trial design simulationsfor separate processing/evaluation by the remote servers 16014, 16016,and/or 16018. Such batch processing may be accomplished in parallel,e.g., distributed parallel processing of replications, e.g., 100replications for up to a maximum number, e.g., ten (10), of batches forseveral designs simultaneously.

In some embodiments, the number of simulated replications used toevaluate a design may be dynamically determined. The number of simulatedreplications may be dynamically evaluated according to results ofsimulations. In some embodiments simulations for a design may beconfigured for a fixed number of replications. As the simulationsprogress, data from the simulations may be analyzed to determine if thenumber of simulations may be decreased or should be increased. Forexample, some embodiments may stop replications when the standard errorof the score estimate is sufficiently small. Embodiments may also adaptthe number of replications to the quality of the design. For example,some embodiments may stop replications when the difference from thelower 99% confidence interval of the best design found so far is higherthan a 99% upper confidence interval of the design being replicated.Embodiments may invoke parallel processing to compute replications inbatches, e.g., one-hundred (100) replications for up to a maximumnumber, e.g., (10), of batches for several designs simultaneously.Adaptive rules, e.g., rules that change over time or in response to aset of conditions, may terminate replication sampling for designs.

Turning to FIG. 161, an embodiment of an apparatus 16100 for providingadaptive replication in clinical trial design simulation is shown. Theapparatus may form part of the 16010 and/or other computing devicesdescribed herein. The apparatus 16100 may include a replication circuit16110, a results interpretation circuit 16112, a performance circuit16114, an adjustment determining circuit 16116, and an adjustmentcircuit 16118. The replication circuit 16110 may be structured toexecute a replication process 16120 that includes a plurality ofreplications 16122, as discussed herein. Execution of the replicationprocess 16120 generates corresponding replication results data 16124. Inembodiments, the replication circuit 16110 may be structured to batchthe plurality of replications 16122 into a plurality of batches forparallel execution on two or more processors, e.g., remote servers16014, 16016, and/or 16018.

The results interpretation circuit 16112 is structured to interpret thereplication results data 16124 of at least one of the replications16122, and the performance circuit 16114 is structured to determine,based at least in part on the replication results data 16124, aperformance criteria value 16126. The adjustment determining circuit16116 is structured to determine, based at least in part on theperformance criteria value 16126, an adjustment value 16128 to thereplication process 16120. The adjustment circuit 16118 is structured toadjust the replication process 16120 based at least in part on theadjustment value 16128.

The performance criteria value 16126 may include and/or be based atleast in part on a standard error. The adjustment determining circuit16116 may be further structured to configure the adjustment value 16128to cease the replication process 16120 when the standard error is belowa threshold.

The performance criteria value 16126 may include and/or be based atleast in part on an upper confidence interval of the clinical trialdesign corresponding to the replication 16122 that generated thereplication results data 16124. In embodiments, the adjustmentdetermining circuit 16116 may be further structured to configure theadjustment value 16128 to cease the replication process 16120 when adifference from a lower confidence interval of another clinical trialdesign (other than the one corresponding to the replication 16122 whichgenerated the replication results 16124) is higher than the upperconfidence interval.

In embodiments, the apparatus 16100 may include a results retrievalcircuit 16130 structured to retrieve at least some of the replicationresults data 16120 from a quick search data structure 16132, which maybe stored in a database, e.g., 16020 (FIG. 160).

Illustrated in FIG. 162 is a method 16200 for providing adaptivereplication in clinical trial design simulation. The method 16200 may beperformed by the server 16010 and/or apparatus 16100 and/or anothercomputing device(s) described herein. The method 16200 includesinterpreting, via at least one processor, e.g., apparatus 16100 (FIG.161), replication results data 16210. As described herein, thereplication results data may form part of a replication process of aclinical trial design simulation, or other type of simulation. Themethod 16200 further includes determining, via the at least oneprocessor, a performance criteria value based at least in part on thereplication results data 16212. The method 16200 further includesdetermining, via the at least one processor and based at least in parton the performance criteria value, an adjustment value 16214. The method16200 further includes, in response to determining the adjustment value,adjusting, via the at least one processor, the replication process16216.

In embodiments, adjusting the replication process 16216 may includeceasing the replication process when the performance criteria valueincludes and/or is based at least in part on a standard error that isbelow a threshold 16218. In embodiments, adjusting the replicationprocess 16216 may include ceasing the replication process when theperformance criteria value incudes and/or is based at least in part onan upper confidence interval of the clinical trial design and adifference from a lower confidence interval of another clinical trialdesign is higher than the upper confidence interval 16220. In suchembodiments, the lower confidence interval and/or the upper confidenceinterval may be 99%. In embodiments, adjusting the replication process16216 may include increasing a number of replications in the replicationprocess 16222. In embodiments, adjusting the replication process 16216may include decreasing a number of replications in the replicationprocess 16222. In some embodiments the number of simulated replicationsused to evaluate a design may be dynamically determined as part of thereplication process or it may be determined outside of the replicationprocess. In embodiments, the number of replications may be fixed basedon data from previously simulated designs.

The method 16200 may further include retrieving at least some of thereplication results data from a quick search data structure 16226. Thequick search data structure may be a SimCube. In embodiments, the quicksearch data structure may be stored in a database, e.g., database 16020(FIG. 160).

As will be appreciated, by providing for dynamic changing/adjusting ofthe number of replications performed as part of a simulation, someembodiments of the present disclosure may reduce the amount of timerequired to simulate a clinical trial design by reducing the number ofreplications in situations where continued evaluations producediminishing returns and by increasing the number of replications insituations where more accuracy is beneficial. In embodiments, thereplication process and/or clinical trial simulation may be based atleast in part on, or form part if, a simulated annealing analysis.Further, in embodiments, machine learning may be used to determine anadjustment to a replication process. For example, a neural network maybe trained to determine, from design and/or scenario criteria, when thenumber of replications should be increased, decreased, and/or when areplication process should be stopped.

Referring now to FIG. 163, embodiments of the current disclosure mayprovide for enhanced simulated annealing (SA) in clinical trial designsimulations and/or other types of simulations. As described elsewhere inthis disclosure, embodiments of the simulation facility 110 (FIG. 1) mayevaluate a clinical trial design by using SA. As will be explained ingreater detail below, some embodiments of the current disclosure providefor modifications to the SA process that reduce the amount of timeand/or computational resources required to complete the analysis. Forexample, certain embodiments may reduce the number of designs simulatedduring SA via machine learning based interpolation and/or sampling ofdesigns based on relationships to a convex hull tunnel derived fromsimulation of the clinical trial designs.

Accordingly, a system 16300 for providing enhanced SA in clinical trialdesign simulation is shown. The system 16300 may include a server 16310having at least one processor and a memory device. The system 16300 mayfurther include an electronic device 16312, one or more remote servers16314, 16316, 16318, and/or a database 16320 which may be in electroniccommunication with the server 16310 and/or each other via a network16322. The server 16310 may form part of and/or host one or more of theplatforms 104 (FIG. 1), 10404 (FIG. 104) and/or 12504 (FIG. 125), e.g.,the simulation facilities 110 (FIG. 1), 10410 (FIG. 104) and/or 12510(FIG. 125); and/or the computational resources 150 (FIG. 1), 10450 (FIG.104), and/or 12550 (FIG. 125).

The server 16310 may be structured to execute a SA process forming partof a clinical trial design simulation. The server 16310 may use machinelearning to predict simulation results, as opposed to performing a moretraditional simulation, for one or more designs identified during the SAprocess. For example, the server 16310 may select an initial clinicaltrial design to serve as the starting point for SA analysis/exploration.The server 16310 may determine the direction in which to move from theinitial clinical trial design and then identify a new design in theselected direction. The server 16310 may then use machine learning topredict simulation results and then begin the process over again untiltermination of the SA path. In certain embodiments, the server 16310 mayreceive and/or generate data defining a convex hull tunnel for theinitially selected clinical trial design. The server may then selectdesigns for inclusion in the SA path based at least in part onrelationships between the designs and the convex hull tunnel.

The electronic device 16312 may be a user device, e.g., 102 (FIG. 1),such as a desktop, laptop, smart device, etc. In embodiments, theelectronic device 16312 may provide for and/or present an interactiveinterface, e.g., 112 (FIG. 1) that presents a plurality of prompts to auser for configuring the clinical trial design and/or SA process. Theelectronic device 16312 may also receive and display the results of theclinical trial simulation, SA process, and/or provide notifications to auser regarding any adjustments made to the SA process by the server16310. The database 16320 may form part of a data facility, e.g., 138(FIG. 1) and store simulation results data. The remote servers 16314,16316, and/or 16318 may form part of a collection of computationresources, e.g., 150 (FIG. 1) which can be accessed by the server 16310to distribute processing tasks.

Illustrated in FIG. 164 is an embodiment of an apparatus 16400 forproviding enhanced simulated annealing. The apparatus 16400 may formpart of the server 16310 and/or other computing devices describedherein. The apparatus 16400 may include a results interpretation circuit16410, a first identification circuit 16412, a performance predictioncircuit 16414, a second identification circuit 16416, a resultsprediction circuit 16418, and a third identification circuit 16420. Inembodiments, the apparatus 16400 may include a convex hullinterpretation circuit 16422, a results determining circuit 16424,and/or a transmission circuit 16426.

As will be appreciated, embodiments of the apparatus 16400 may includevarious combinations of the circuit shown in FIG. 164 wherein somecircuits are included while others are excluded. For example, anembodiment may include the convex hull interpretation circuit 16422, thefirst identification circuit 16412, the performance prediction circuit16414, the second identification circuit 16416, the results determiningcircuit 16424, and the third identification circuit 16420 but notinclude the results interpretation circuit 16410, the performanceprediction circuit 16414, the results prediction circuit 16418, and/orthe transmission circuit 16426. Further, in embodiments, the firstidentification circuit 16412, the second identification circuit 16416and/or the third identification circuit 16420 may be combined into asingle identification circuit as indicated by the dashed box 16428.

The results interpretation circuit 16410 may be structured to interpretinitial simulation results data 16430 for a set of clinical trialdesigns. The first identification circuit 16412 is structured toidentify an initial clinical trial design 16432 based at least in parton the initial simulation results data 16430. The performance predictioncircuit 16414 is structured to predict performance data 16434 forclinical trial designs related to the initial clinical trial design16432 based at least in part on varying parameters for the initialclinical trial design 16432. The second identification circuit 16416 isstructured to identify a first new clinical trial design 16436 forsimulation based on the predicting. The results prediction circuit 16418is structured to predict, via machine learning, first simulation resultsdata 16438 for the first new clinical trial design 16436. The thirdidentification circuit 16420 is structured to identify, based at leastin part on the first simulation results data 16438, a second newclinical trial design 16440 for simulation by varying parameters of thefirst new clinical trial design 16436.

The convex hull interpretation circuit 16422 is structured to interpretconvex hull tunnel data 16442 corresponding to a convex hull tunneldefined, in part, by the set of clinical trial designs. The firstidentification circuit 16412 may be structured to identify the initialclinical trial design 16432 based at least in part on the convex hulltunnel data 16442. The second identification circuit 16416 may bestructured to identify the first new clinical trial design 16436 basedon the performance criteria data 16434 and on the convex hull tunneldata 16442. The results determining circuit 16424 may be structured todetermine first simulation results data 16444 for the first new clinicaltrial design 16436. The third identification circuit 16420 may bestructured to identify, based at least in part on the first simulationresults data 16444, the second new clinical trial design 16440 forsimulation by varying parameters of the first new clinical trial design16436.

In embodiments, the machine learning may be based at least in part on aneural network and/or a regression model, e.g., a regression tree.Embodiments of the machine learning may be trained via supervisedlearning on training sets. Such training sets may include a series ofdesigns with known performance results. Data from the previouslycalculated neighboring designs may be leveraged to train a neuralnetwork via reinforcement learning to predict the value of a design asopposed to simulating the design. The training set may include a subsetof values of scenario parameters and the predicted output may be valuesfor the one or more designs.

Shown in FIG. 165 is a design space 16500 with designs 16510 and 16512,for which simulation results data is known, and design 16514, for whichsimulation results data is unknown. The machine learning may be used topredict the simulation results data of design 16514 from the simulationresults data of neighboring designs, e.g., 16512. As used herein,“neighboring” designs are designs that are close to one another indesign space 16500 and/or other spaces, as would be understood by thoseof skill in the art. For example, designs 16512 are neighboring designsto design 16514, while designs 16510 are not neighboring designs todesign 16514. As will be understood, in embodiments, feeding simulationresults of neighboring designs 16512 into the machine learning model mayprovide for interpolation of the design 16514.

Turning to FIG. 166, a convex hull tunnel 16600 generated by convex hullpeeling (as disclosed herein), is shown. The convex hull tunnel may havean upper bound 16610, a lower bound 16612, and a center line 16614.Designs 16616 may be selected for inclusion in the SA path based ontheir relationship to the convex hull tunnel 16600. For example, inembodiments, a penalty function may be used to score and/or rank thedesigns 16616 based on their distance from the centerline 16614, lowerbound 16612, and/or upper bound 16610, for inclusion in a SA path. Inembodiments, the penalty function may encourage/promote selection ofdesigns 16616, for inclusion in a SA path, that are closer to the centerline 16614 over designs 16616 that are father away from the center line16614. In other words, some embodiments of the disclosure may discourageuse of designs 16616, in a SA path, that are father away from the centerline 16614.

Referring now to FIG. 167, a method 16700 for enhanced simulatedannealing is shown. The method may be performed by the server 16310(FIG. 163) and/or the apparatus 16400 (FIG. 164). The method 16700includes interpreting initial simulation results data for a set ofclinical trial designs 16710 and identifying an initial clinical trialdesign based at least in part on the initial simulation results data16712. The method 16710 further includes predicting performance data forclinical trial designs related to the initial clinical trial designbased at least in part on varying parameters for the initial clinicaltrial design 16714. The method 16700 further includes identifying afirst new clinical trial design for simulation based on the predicting16716, and predicting, via machine learning, first simulation resultsdata for the first new clinical trial design 16718. The method 16700further includes identifying, based at least in part on the firstsimulation results data, a second new clinical trial design forsimulation by varying parameters of the first new clinical trial design16720. In embodiments, the method 16700 may further include interpretingconvex hull tunnel data corresponding to a convex hull tunnel defined,in part, by the set of clinical trial designs 16722. In suchembodiments, identifying the first new clinical trial design forsimulation 16716 may be further based at least in part on the convexhull tunnel data.

Illustrated in FIG. 168 is another method 16800 for enhanced simulatedannealing. The method may be performed by the server 16310 (FIG. 163)and/or the apparatus 16400 (FIG. 164). The method 16800 includesinterpreting convex hull tunnel data corresponding to a convex hulltunnel defined, in part, by a set of clinical trial designs 16810, andidentifying an initial clinical trial design based at least in part onthe convex hull tunnel data 16812. The method 16800 further includespredicting performance for clinical trial designs based at least in parton varying parameters for the initial clinical trial design 16814, andidentifying a first new clinical trial design for simulation based onthe predicting and on the convex hull tunnel data 16816. The method16800 further includes determining first simulation results for thefirst new clinical trial design 16818, and identifying, based at leastin part on the first simulation results, a second new clinical trialdesign for simulation by varying parameters of the first new clinicaltrial design 16820. In embodiments, determining first simulation resultsfor the first new clinical trial design 16818 may include predicting thefirst simulation results via machine learning 16822. In embodiments, themethod 16800 may further include interpreting initial simulation resultsdata 16824.

Illustrated in FIG. 169 is yet another method 16900 for enhancedsimulated annealing. The method 16900 includes interpreting initialsimulation results data for a set of clinical trial designs 16910, andidentifying, based at least in part on the initial simulation resultsdata, a clinical trial design for simulation 16912. The method 16910further includes predicting, via machine learning and based at least inpart on the initial simulation results data, simulation results data forthe clinical trial design 16914; and transmitting the simulation resultsdata 16916.

In embodiments, one or more of the method of enhanced simulatedannealing described herein may be form part of (or work in conjunctionwith) the recommendation engine/algorithm. For example, embodiments ofthe recommendation engine may use enhanced simulated annealing to findcandidate designs for recommendation. In embodiments, enhanced simulatedannealing may be used to dynamically update one or more parameters of adesign, which may be in real-time. For example, one or more parametersof a design corresponding to an ongoing trial may analyzed and/oradjusted based on results from an enhanced simulated annealing analysis.In embodiments, the one or more parameters may be updated while thetrial is being conducted, i.e., during the trial. In embodiments,enhanced simulated annealing may be used to determine changes in theoutcome of an ongoing trial resulting from potential adjustments to thecorresponding design.

Referring now to FIG. 170, a system 17000 for design exploration andsearch is shown. The design exploration and search may be based at leastin part on data structures referred to herein as “quick search datastructures”, e.g., “design libraries”. The quick search data structuresmay enable efficient mapping and/or comparison within a design space andcriteria space. The data structures may be configured to enablecomparing designs across multiple variables, (e.g., finding “similardesigns” for a plurality of criteria). Embodiments of the quick searchdata structures may have geometries that localize designs resulting insimilar criteria, i.e., different designs that result in the sameoutputs are located next to (or near) each other. Designs may bepopulated into the quick search data structures after being simulated.Thus, if a design is selected at a later point to be simulated, thequick search data structure can be checked prior to simulation of thedesign to see if the data for the design already exists. A design doesnot need to be simulated if it is already in the quick search datastructure. Thus, a first simulated annealing (or other design spaceexploration approach) may cause a first set of designs to be simulatedand populated into a quick search data structure. At a later point intime, a second simulated annealing (or other design space explorationapproach) may select a second set of designs to be simulated, whereinthe quick search data structure provides for the ability to determinedesigns that overlap the first and second sets to avoid theirre-simulation.

Accordingly, the system 17000 may include a server 17010 having at leastone processor and a memory device. The system 17000 may further includean electronic device 17012, one or more remote servers 17014, 17016,17018, and/or a database 17020 which may be in electronic communicationwith the server 17010 and/or each other via a network 17022. The server17010 may form part of and/or host one or more of the platforms 104(FIG. 1), 10404 (FIG. 104) and/or 12504 (FIG. 125), e.g., the simulationfacilities 110 (FIG. 1), 10410 (FIG. 104) and/or 12510 (FIG. 125);and/or the computational resources 150 (FIG. 1), 10450 (FIG. 104),and/or 12550 (FIG. 125).

The server 17010 may be structured to execute a SA process forming partof a clinical trial design simulation. The server 17010 may use a quicksearch data structure to determine/retrieve/lookup results ofsimulations (if previously simulated), as opposed to performing a moretraditional simulation, for one or more designs identified during an SAprocess (or other searching procedure). For example, the server 17010may select an initial clinical trial design to serve as the startingpoint for SA analysis/exploration. The server 17010 may determine thedirection in which to move from the initial clinical trial design andthen identify a new design in the selected direction. The server 17010may then check, via a quick search data structure, to see if results forthe design have already been simulated, and then begin the process overagain until termination of the SA path.

The electronic device 17012 may a user device, e.g., 102 (FIG. 1), suchas a desktop, laptop, smart device, etc. In embodiments, the electronicdevice 17012 may provide for and/or present an interactive interface,e.g., 112 (FIG. 1) that presents a plurality of prompts to a user forconfiguring the clinical trial design and/or SA process. The electronicdevice 17012 may also receive and display the results of the clinicaltrial simulation, SA process, properties of the quick search datastructure, and/or receive and/or provide notifications from the serverto a user regarding the SA process and/or quick search data structure.The database 17020 may form part of a data facility, e.g., 138 (FIG. 1)and store the quick search data structure in memory. The remote servers17014, 17016, and/or 17018 may form part of a collection of computationresources, e.g., 150 (FIG. 1) which can be accessed by the server 17010to distribute processing tasks.

In embodiments, the quick search data structure may take the form of aSimCube having a structure that is a natural fit for simulated annealingalgorithms, e.g., a single step in simulated annealing involves movingfrom a position/cell (within the SimCube) to an adjacent position/cell(within the SimCube) by changing just one design parameter or onescenario variable. The number of iterations of a simulated annealingpath from a design to a locally optimal design may be the Manhattandistance between the two designs in the hypercube. For example, inembodiments, the quick search data structure may be a hypercube having anumber of dimensions equal to the sum of the number of design parametersand the number of scenario variables that form a plurality of cells,each of which may contain a vector of simulation results that mayinclude a multi-criteria vector.

Turning now to FIGS. 171(a-b), an example of a quick search datastructure 17100 in the form of a SimCube is shown, wherein the exampledata set corresponds to one thousand (1,000) replications for each of40,824 scenario-design combinations, e.g., fifty-four (54) scenarios byseven-hundred and fifty-six (756) designs with three (3) criteria(power, trial costs, and trial duration). The quick search datastructure 17100 may include a results data repository 17110 and an index17112. As shown in FIGS. 171(a-b), the results data repository 17110 maybe expressed as a flat file, e.g., a text file, where each rowrepresents the results of simulating a particular design and/or designreplication. Each row may include a key determined, in part, by aranking of distinct values of design parameters 17114 in the index17112. For example, the key for row “1724” is “4,3,3,4,2,4”, wherein thevalue of ‘70’ for “% Events Observed at Interim” is assigned a rank of4, the value of ‘0.5’ for “min Promising Zone Point” is assigned a rankof ‘3’, the value of ‘0.99’ for “max Promising Zone Point” is assigned aran of 3, the value of ‘1.733333’ for “max Events Multiplier” isassigned a rank of ‘4’, the value of ‘1.5’ for “max Subjs Multiplier” isassigned a rank of ‘2’, and the value of ‘0.7’ for “Adaptive Wt1” isassigned a rank of ‘4’. Thus, the index 17112 can be used to locate adesign with a desired set of design parameters 17114 with the followingrelationship: SimCube Row # for a design=(sum of (rank*correspondingrank multiplier) over all dimensions)−sum (rank multipliers). Forexample, the row of a design having ‘70’ for “% Events Observed atInterim”, ‘0.5’ for “min Promising Zone Point”, ‘0.99’ for “maxPromising Zone Point”, ‘1.733333’ for “max Events Multiplier”,‘1.777778’ for “max Subjs Multiplier”, and ‘0.5’ for “Adaptive Wt1” canbe calculated assum((4*432)+(3*144)+(3*48)+(4*12)+(3*4)+(2*1))−(432+144+48+12+4+1)=1725,with a corresponding key of ‘4,3,3,4,3,2’. In embodiments, therepository 17110 can be stored in a compressed form where empty rows canbe removed to save memory space. For example, in the scenario shown inFIGS. 171(a-b), the total number of empty cells/rows in the repository17110 may be 40,068, i.e., there repository 17110 may only contain theresults for seven-hundred and fifty-six designs. Thus, where the fulldesign of such a SimCube has dimensions of 4×3×4×4×4 with 1,728 cells,the corresponding density of the SimCube would be 43.75%. In embodimentswhere the repository 17110 is compressed, the rows may be sorted inorder of the full row value of a design so that a binary search may beused. In embodiments, the quick search data structure 17100 may includeone or more of heaps and/or hash tables (using the full table row valueas a key), e.g., some embodiments may combine aspects of SimCubes withheaps and/or hash tables, which may provide for intermediate time-memoryusage trade-offs.

Some embodiments of the current disclosure may also include networkimplementations of SimCubes, wherein each design may be a node withinundirected edges joining each pair of designs that differ in rank inonly one parameter for which the ranks differ by one (1). In suchembodiments, the network data structure may be useful to efficientlycompute neighbors to a design of interest and/or for constructingclusters of similar designs. In embodiments, samples of scenario-designcombinations, rather than simulating each design for all scenarios, maybe used. For example, embodiments of the quick search data structuresdescribed herein may be extended to this setting by increasing thenumber of parameters (and hence SimCube dimensions) to be the sum ofdesign and scenario parameters. As will be further understood,embodiments of the quick search data structures described herein mayalso be used for simulations of clinical trials operations such asrecruitment forecasting and drug supply.

Illustrated in FIG. 172 is a method 17200 of design exploration andsearch that utilizes a quick search data structure with simulatedannealing (SA). A set of initial combination of design parameters isdefined 17210. Exclusion criteria are tested for 17212 and adetermination is made as to whether the combination of design parametersshould be excluded from the SA path 17214 and written to an exclusionlog 17216. Combinations passing the exclusion test 17214 are thensearched for (looked up) in a quick search data structure 17218 and17220. If corresponding simulation results are found in the quick searchdata structure, they are written to a details log 17222. Ifcorresponding simulation results are not found, then the combination ofdesign parameters is simulated 17224 with the results written to thequick search data structure 17226. After the results have been retrievedand/or generated via simulation, they may be checked against the resultsof prior replications to determine if they are superior/optional ascompared to the results of two or more previous replications 17228, andif so, written to an output log 17230. Results that are not superior, ascompared to the two or more previous replications, are then evaluatedfor inclusion in the SA path 17232 and 17234, the next parametercombination/design replication is retrieved and/or generated 17238, andthe process beings again until there are no more replications toevaluate. Design parameter combinations that are written to the outputlog may also be tested to determine if they are the best results thusfar, and if so, written to a best output log 17240 and 17242.

Referring now to FIG. 173, in embodiments, simulated annealing mayprovide for the identification of similar designs by exploring region ofinterest, e.g., local neighborhoods, around a particular design.Accordingly, another method 17300 for design exploration and search isshown that finds/evaluates one or more designs within a distance dand/or score difference Δê. The method 17300 may be based at least inpart on one or more of the following premises: 1) that the startingpoint for design search is a “good” design, e.g., can be found using aSA process; 2) that SA can be used to find twin (or close to twin)designs within a small score variation Δê, provided the result is withind Manhattan distance of the starting design; and 3) that multipledesigns can be found by parallel instances. As such, the method 17300may provide for rapid discovery of equally (or close to equally) “good”designs in close proximity to a desired design. The method 17300 mayinclude a user providing a “good”/desirable design for use as a startingpoint 17310. A use score of the initially provided design may then becalculated as Z0 17312. A proximal design may then be selected 17314. AnSA process may then be executed until Z0 is accomplished wherein eachreplication is evaluated to see if it is within a Manhattan distance d,and if yes, the simulation results are written to an output log 17316,17318, and 17320. Replications not falling within d may be discarded17322.

Turning to FIG. 174, another method 17400 of design exploration andsearch may be based on one or more of the following premises: 1)near-optimal designs tend to have many “twins” in terms of same orsimilar scores; 2) once one near-optimal design is found, the score maybe used as a target score for finding other designs with other startingpoints that are twins or are otherwise very close; and 3) such twins aretypically found in a small number of replicates/engine calls. As such,the method 17400 may include defining an initial parameter combination17400, executing a SA process with a large number of replicates R 17412,and noting the best score found Z0 17414. The method 17400 may thenenter a loop where various starting design parameter combinations aretested with a SA process until Z0 is accomplished with the resultswritten to an output log 17416, 17418, and 17420.

Referring now to FIG. 175, another method 17500 for design explorationand search may be based on one or more of the following premises: 1) thestarting point may be a user-specified design already having a goodscore and desirable attributes (parameter combination); and 2) SA willfind twin (or close to twin) designs within the desired type (e.g.,Sample Size Re-estimation (SSR) or Group Sequential). The method 17500may include a user providing a “good”/desirable design for use as astarting point 17510. The score of the provided design may be used as Z017512. The method 17500 may then enter a loop where subsequent proximaldesigns are selected and evaluated with SA until Z0 is accomplished withthe results written to an output log 17514, 17516, and 17518.

Shown in FIG. 176 is a graphical user interface 17600 that may beprovided on the electronic device 17012 (FIG. 170) for configuring theserver 17010 (FIG. 170) or other device executing one or more of themethods for design exploration and search disclosed herein. Theinterface 17600 may include fields for specifying the Manhattan distanced 17610, Δê 17612, and/or one or more design parameters 17614. A button17616 (or other user input widget) may provide for execution of one ormore of the methods described herein using the values specified in theinterface 17600 to populate the property 17614 and performance criteria17618 of one or more neighboring designs 17622.

Illustrated in FIG. 177 is another method 17700 for design explorationand search. The method 17700 may include allocating memory, in a memorydevice, that defines a quick search data structure having a plurality ofstorage cells 17710 and simulating a plurality of clinical trial designsto obtain a plurality of simulation results 17712. In embodiments, eachof the plurality of simulation results may correspond to one of theplurality of clinical trial designs. The method 17700 may furtherinclude storing each of the plurality of simulation results in acorresponding one of the plurality of storage cells based on one or morerelationships between two or more of the plurality of clinical trialdesigns 17714. In embodiments, the one or more relationships between thetwo or more of the plurality of clinical trial designs is based at leastin part on the value of parameters for each of the two or more of theplurality of clinical trial designs. In embodiments, the method 17700may further include scoring the two or more of the plurality of clinicaltrial designs based at least in part on the value of the parameters17716 and determining whether the two or more of the plurality ofclinical trial designs are similar designs 17718. Determining whetherthe two or more of the plurality of clinical trial designs are similardesigns may include determining if the two or more of the plurality ofclinical trial designs are within an epsilon of a desired score 17720and/or determining if the two or more of the plurality of clinical trialdesigns are within an epsilon of each other 17722. In embodiments, thequick search data structure may be a SimCube as described herein.

Referring to FIG. 178, another method 17800 of design exploration andsearch includes obtaining initial simulation results for a set ofclinical trial designs 17810 and identifying an initial clinical trialdesign based at least in part on the initial simulation results 17812.The method 17800 further includes predicting performance for clinicaltrial designs related to the initial clinical trial design based atleast in part on varying parameters for the initial clinical trialdesign 17814 and identifying a first new clinical trial design forsimulation based on the predicting 17816. The method 17800 furtherincludes determining if a quick search data structure contains firstsimulation results for the first new clinical trial design 17818 and ifthe quick search data structure does not contain the first simulationresults, simulating the first new clinical trial design to obtain thefirst simulation results 17820. The method 17800 further includesidentifying, based at least in part on the first simulation results, asecond new clinical trial design for simulation by varying parameters ofthe first new clinical trial design 17822. In embodiments, the method17800 may include storing the first simulation results in the quicksearch data structure 17824, which may include determining one or morerelationships between the first new clinical trial design and anotherclinical trial design stored in the quick search data structure 17826.In embodiments the one or more relationships between the new clinicaltrial design and the other clinical trial design may be based at leastin part on the value of the parameters for the first new clinical trialdesign and parameters of the other clinical trial design.

Shown in FIG. 179 is another method 17900 for design exploration andsearch. The method 17900 includes interpreting, via at least oneprocessor, simulation results data for a set of clinical trial designs17910, and populating, via the at least one processor, a quick searchdata structure, defined within a memory device, with the simulationresults data 17912. The method 17900 may further include identifying,via the at least one processor, a region of interest within at least oneof a performance criteria space of the set of clinical trial designs orthe quick search data structure 17914. Referring briefly to FIG. 180, anexample performance criteria space 18000 is shown having a plurality ofdesigns 18010. In embodiments, a region of interest may be a region18012 in the performance criteria space 18000 that is close to agrouping of designs but itself devoid of a design. A region of interestmay also be a region 18014 that is distal from designs and/or encircledby designs, e.g., a void. It is to be understood that regions ofinterest may take other forms as well, i.e., regions that appearinteresting to a user and which may contain designs the user wishes tosearch and/or evaluate, and that similar regions of interest may befound in a quick search data structure and/or various tornado diagrams,as described herein. Accordingly, returning back to FIG. 179,identifying a region of interest may include determining a void 17916.The method 17900 may further include identifying, via at least oneprocessor, a first clinical trial design based at least in part on theregion of interest 17918, and determining, via the at least oneprocessor and based at least in part on the quick search data structureand the first clinical trial design, a second clinical trial design17920. Data corresponding to the second clinical trial design may thenbe transmitted, e.g., sent to the electronic device 17012 (FIG. 170) fordisplay to a user 17922. In embodiments determining the second clinicaltrial design may include determining that the second clinical trialdesign is within a Manhattan distance within the quick search datastructure of the first clinical trial design 17924 and/or determiningthat the second clinical trial design is within an epsilon of a desiredscore 17926. In embodiments, the region of interest corresponds to twoor more similar designs.

In embodiments, the relationship for storing designs in the quick searchdata structure may be based at least in part on machine learning. Forexample, a machine learning module, e.g., a neural network, may betrained, via supervised and/or unsupervised learning, to determine oneor more relationships, which may optimize the quick search datastructure for a particular evaluation session.

FIGS. 181(a-k) show an example use case of the platform describedherein. The platform may include various interfaces for inputting andanalyzing data. The example use case shows how users may use theplatform to specify design parameters, simulate designs, analyze thesimulated data, and identify globally optimum or nearly globally optimumdesigns for a trial. The platform may be used to identify an efficientdesign that addresses requirements for criteria (such as power, samplesize, trial durations, cost, etc.). In the example, the platform may beused to answer questions related to what is the optimal sample size andnumber of events, what is the optimal number and timing of interimanalyses, what is the optimal alpha spending function, and the like.

In embodiments, data entry into the platform may involve data entry intoone or more forms. In embodiments, forms may be web based or browserbased applications, native applications, or other executable code thatproves an interface for data entry. In some embodiment, data entry maybe provided with a specification file that that may be read by theplatform or via an API connection to another platform or data source.

FIG. 181(a) shows one example of an initial data entry interface forspecifying design and simulation parameters into the platform. In thisexample, data may be entered via one or more data entry fields (dropdown menus, input boxes, lists and the like). Data entry may include aseries of tabs or screens that may guide the user to enter the requireddata. The first data entry may be related to the “Plan” for the clinicaltrial. As shown in FIG. 181(a), entries related to the “Plan” mayinclude general aspects defining types of designs. Data entry mayinclude specifying a Target Population, Control Arm, Treatment Arm,Endpoints and the like for the study.

FIG. 181(b) shows one example of an interface for data entry forspecification of design for the study. As shown in the figure, entriesrelated to the “Design” may include specifications of designs and mayinclude data entry for the type of statistical designs, the number ofarms for the design and the like. Data entry may further include datarelated to the design such as hypothesis, follow up sample size, numberof events, allocation ratio, the type statistical design, and the like.Data entry may include specifications related to early stoppingparameters, sample size re-estimation parameters, and the like.

The next data entry may be related to the “Response” parameters. Asshown in FIG. 181(c), entries related to the “Response” may include dataentry to define the time-to-event distributions that may be used by theplatform to simulate the individual subjects' data.

The next data entry may be related to the enrollment parameters. Asshown in FIG. 181(d), entries related to “Enrollment” may include dataentry to target populations, population distributions, geography,enrollment, and the like.

The next data entry may be related to the cost parameters. As shown inFIG. 181(e), entries related to the “Costs” may include data entry todefine costs per subject or the average investigator grant per patient.

Another portion of the data entry may be related to revenue parameters.As shown in FIG. 181(f), entries related to the “Revenues” may includedata entry to define when and how the expected revenue will begenerated. Data entry may include a regulatory review period in years,annual revenue in a peak year, time to peak annual revenue, and otherparameters, including as shown in the figure.

Another data entry may be related to the scoring parameters. As shown inFIG. 181(g), entries related to the “Scoring” may include data entry todefine weights for computing a score. Data entry may include selectionsand weights (in % of total score) to minimize study cost, minimize studyduration, maximize power, and/or minimize sample size.

Throughout the data entry process, the input advisor may monitor userentries and identify conflicts in data values and/or suggest entries ofdata values. In some instances, the input advisor may predict, based onhistorical data and/or data entry what values or types of data areassociated with some inputs. The input advisor may highlight or identifyranges of values that are consistent with historical data of data entryvalues. In the case where some data values are outside of expected orhistorical data values the entry area may be flagged or highlighted forreview.

Once data is entered, the entry data from each input field are assembledand compiled to define the simulation set via the “Collections” tab asshown in FIG. 181(h). Once the data is assembled it may be formatted togenerate models that may be ready for simulation. In this example, 540models are generated based on the input data. Assembly of data mayinclude generating design and scenario permutations for simulation.Assembly of data may include removing scenarios or design combinationsthat are invalid or unlikely.

In some embodiments, generation of models may be a trigger to requestand allocate computation resources for simulation. In the case of batchmode computation, the resources may be requested before they are neededto allow time for the allocation.

In the next step, simulations may be started by selecting the “simulate”button. In embodiments, before simulations are queued to run, the usermay be informed of the cost of the simulations in units such as dollarsor credits. Then the “Simulate” button may be clicked to start thesimulations. The models for each simulation may be submitted to one ormore engines for simulation. The engines may use one or more cloudcomputing resources to execute the models to determine the performanceof each design model.

In embodiments, simulations may be exhaustive for all of the models. Insome cases, only a partial set of the models may be simulated. In someembodiments, the partial set of models may be randomly selected or maybe selected based on predictions (based on historical data) as to whichdesigns in the models are likely to have the best performance for thespecified criteria. In some embodiments, simulated annealing may be usedto simulate a partial set of the models. Simulated annealing may be usedto search for local maxima in performance space.

When the simulations end, the user may be prompted to view the resultsof the simulations via the tradeoff advisor. Clicking the “View Results”button may initiate calculation of scores and robustness scores from thesimulation results and may load the simulation results into the tradeoffadvisor. In embodiments, simulated data may be analyzed using one ormore Pareto, convex hull, or other techniques to identify the optimum ornear optimum designs. These Pareto, convex hull, and other recommendeddesigns may be marked or highlighted in various interfaces of thetradeoff advisor.

In embodiments, the tradeoff advisor may include interfaces and tools toexplore performance parameters of designs, compare designs, initiateadditional simulations, and the like. The tradeoff advisor may includeheatmaps as shown in FIG. 181(i). The heatmaps may provide a visual viewof the relative performance of the simulated designs for one or moreperformance parameters. The heatmap may be sorted, filtered, rearrangedto help identify designs with the desired performance. The heatmap inFIG. 181(i) shows designs sorted by robustness score, scenarios sortedby hazard ratio and by control group rate. Users may explore the designsby marking relative cells, viewing details of each design (such as withthe tooltip data shown in FIG. 181(i)).

In embodiments, the tradeoff advisor may include scatterplots as shownin FIG. 181(j). The scatterplot in the upper left is power by duration;note that the 3 clustered rows correspond to the three HR's 0.67, 0.7,and 0.73 from top to bottom.

In embodiments, tradeoff advisor may include boxplots as shown in FIG.181(k) The boxplots may show the distributions of duration, power, cost,and score for simulated designs.

In embodiments, the tradeoff advisor may include additional interfacesfor comparing designs (such as card interfaces, tornado diagrams, andthe like described herein). Additional interfaces may be shown allowingusers to drill down or see related designs that are similar (such astwins, siblings, designs that are within an epsilon-distance of arecommended or selected design, etc.).

The methods and systems described herein may be deployed in part or inwhole through a machine having a computer, computing device, processor,circuit, and/or server that executes computer readable instructions,program codes, instructions, and/or includes hardware configured tofunctionally execute one or more operations of the methods and systemsherein. The terms computer, computing device, processor, circuit, and/orserver, (“computing device”) as utilized herein, should be understoodbroadly.

An example computing device includes a computer of any type, capable toaccess instructions stored in communication thereto such as upon anon-transient computer readable medium, whereupon the computer performsoperations of the computing device upon executing the instructions. Incertain embodiments, such instructions themselves comprise a computingdevice. Additionally or alternatively, a computing device may be aseparate hardware device, one or more computing resources distributedacross hardware devices, and/or may include such aspects as logicalcircuits, embedded circuits, sensors, actuators, input and/or outputdevices, network and/or communication resources, memory resources of anytype, processing resources of any type, and/or hardware devicesconfigured to be responsive to determined conditions to functionallyexecute one or more operations of systems and methods herein.

Network and/or communication resources include, without limitation,local area network, wide area network, wireless, internet, or any otherknown communication resources and protocols. Example and non-limitinghardware and/or computing devices include, without limitation, a generalpurpose computer, a server, an embedded computer, a mobile device, avirtual machine, and/or an emulated computing device. A computing devicemay be a distributed resource included as an aspect of several devices,included as an interoperable set of resources to perform describedfunctions of the computing device, such that the distributed resourcesfunction together to perform the operations of the computing device. Incertain embodiments, each computing device may be on separate hardware,and/or one or more hardware devices may include aspects of more than onecomputing device, for example as separately executable instructionsstored on the device, and/or as logically partitioned aspects of a setof executable instructions, with some aspects comprising a part of oneof a first computing device, and some aspects comprising a part ofanother of the computing devices.

A computing device may be part of a server, client, networkinfrastructure, mobile computing platform, stationary computingplatform, or other computing platform. A processor may be any kind ofcomputational or processing device capable of executing programinstructions, codes, binary instructions and the like. The processor maybe or include a signal processor, digital processor, embedded processor,microprocessor or any variant such as a co-processor (math co-processor,graphic co-processor, communication co-processor and the like) and thelike that may directly or indirectly facilitate execution of programcode or program instructions stored thereon. In addition, the processormay enable execution of multiple programs, threads, and codes. Thethreads may be executed simultaneously to enhance the performance of theprocessor and to facilitate simultaneous operations of the application.By way of implementation, methods, program codes, program instructionsand the like described herein may be implemented in one or more threads.The thread may spawn other threads that may have assigned prioritiesassociated with them; the processor may execute these threads based onpriority or any other order based on instructions provided in theprogram code. The processor may include memory that stores methods,codes, instructions and programs as described herein and elsewhere. Theprocessor may access a storage medium through an interface that maystore methods, codes, and instructions as described herein andelsewhere. The storage medium associated with the processor for storingmethods, programs, codes, program instructions or other type ofinstructions capable of being executed by the computing or processingdevice may include but may not be limited to one or more of a CD-ROM,DVD, memory, hard disk, flash drive, RAM, ROM, cache and the like.

A processor may include one or more cores that may enhance speed andperformance of a multiprocessor. In embodiments, the process may be adual core processor, quad core processors, other chip-levelmultiprocessor and the like that combine two or more independent cores(called a die).

The methods and systems described herein may be deployed in part or inwhole through a machine that executes computer readable instructions ona server, client, firewall, gateway, hub, router, or other such computerand/or networking hardware. The computer readable instructions may beassociated with a server that may include a file server, print server,domain server, internet server, intranet server and other variants suchas secondary server, host server, distributed server and the like. Theserver may include one or more of memories, processors, computerreadable transitory and/or non-transitory media, storage media, ports(physical and virtual), communication devices, and interfaces capable ofaccessing other servers, clients, machines, and devices through a wiredor a wireless medium, and the like. The methods, programs, or codes asdescribed herein and elsewhere may be executed by the server. Inaddition, other devices required for execution of methods as describedin this application may be considered as a part of the infrastructureassociated with the server.

The server may provide an interface to other devices including, withoutlimitation, clients, other servers, printers, database servers, printservers, file servers, communication servers, distributed servers, andthe like. Additionally, this coupling and/or connection may facilitateremote execution of instructions across the network. The networking ofsome or all of these devices may facilitate parallel processing ofprogram code, instructions, and/or programs at one or more locationswithout deviating from the scope of the disclosure. In addition, all thedevices attached to the server through an interface may include at leastone storage medium capable of storing methods, program code,instructions, and/or programs. A central repository may provide programinstructions to be executed on different devices. In thisimplementation, the remote repository may act as a storage medium formethods, program code, instructions, and/or programs.

The methods, program code, instructions, and/or programs may beassociated with a client that may include a file client, print client,domain client, internet client, intranet client and other variants suchas secondary client, host client, distributed client and the like. Theclient may include one or more of memories, processors, computerreadable transitory and/or non-transitory media, storage media, ports(physical and virtual), communication devices, and interfaces capable ofaccessing other clients, servers, machines, and devices through a wiredor a wireless medium, and the like. The methods, program code,instructions, and/or programs as described herein and elsewhere may beexecuted by the client. In addition, other devices required forexecution of methods as described in this application may be consideredas a part of the infrastructure associated with the client.

The client may provide an interface to other devices including, withoutlimitation, servers, other clients, printers, database servers, printservers, file servers, communication servers, distributed servers, andthe like. Additionally, this coupling and/or connection may facilitateremote execution of methods, program code, instructions, and/or programsacross the network. The networking of some or all of these devices mayfacilitate parallel processing of methods, program code, instructions,and/or programs at one or more locations without deviating from thescope of the disclosure. In addition, all the devices attached to theclient through an interface may include at least one storage mediumcapable of storing methods, program code, instructions, and/or programs.A central repository may provide program instructions to be executed ondifferent devices. In this implementation, the remote repository may actas a storage medium for methods, program code, instructions, and/orprograms.

The methods and systems described herein may be deployed in part or inwhole through network infrastructures. The network infrastructure mayinclude elements such as computing devices, servers, routers, hubs,firewalls, clients, personal computers, communication devices, routingdevices and other active and passive devices, modules, and/or componentsas known in the art. The computing and/or non-computing device(s)associated with the network infrastructure may include, apart from othercomponents, a storage medium such as flash memory, buffer, stack, RAM,ROM and the like. The methods, program code, instructions, and/orprograms described herein and elsewhere may be executed by one or moreof the network infrastructural elements.

The methods, program code, instructions, and/or programs describedherein and elsewhere may be implemented on a cellular network havingmultiple cells. The cellular network may either be frequency divisionmultiple access (FDMA) network or code division multiple access (CDMA)network. The cellular network may include mobile devices, cell sites,base stations, repeaters, antennas, towers, and the like.

The methods, program code, instructions, and/or programs describedherein and elsewhere may be implemented on or through mobile devices.The mobile devices may include navigation devices, cell phones, mobilephones, mobile personal digital assistants, laptops, palmtops, netbooks,pagers, electronic books readers, music players and the like. Thesedevices may include, apart from other components, a storage medium suchas a flash memory, buffer, RAM, ROM and one or more computing devices.The computing devices associated with mobile devices may be enabled toexecute methods, program code, instructions, and/or programs storedthereon. Alternatively, the mobile devices may be configured to executeinstructions in collaboration with other devices. The mobile devices maycommunicate with base stations interfaced with servers and configured toexecute methods, program code, instructions, and/or programs. The mobiledevices may communicate on a peer to peer network, mesh network, orother communications network. The methods, program code, instructions,and/or programs may be stored on the storage medium associated with theserver and executed by a computing device embedded within the server.The base station may include a computing device and a storage medium.The storage device may store methods, program code, instructions, and/orprograms executed by the computing devices associated with the basestation.

The methods, program code, instructions, and/or programs may be storedand/or accessed on machine readable transitory and/or non-transitorymedia that may include: computer components, devices, and recordingmedia that retain digital data used for computing for some interval oftime; semiconductor storage known as random access memory (RAM); massstorage typically for more permanent storage, such as optical discs,forms of magnetic storage like hard disks, tapes, drums, cards and othertypes; processor registers, cache memory, volatile memory, non-volatilememory; optical storage such as CD, DVD; removable media such as flashmemory (e.g. USB sticks or keys), floppy disks, magnetic tape, papertape, punch cards, standalone RAM disks, Zip drives, removable massstorage, off-line, and the like; other computer memory such as dynamicmemory, static memory, read/write storage, mutable storage, read only,random access, sequential access, location addressable, fileaddressable, content addressable, network attached storage, storage areanetwork, bar codes, magnetic ink, and the like.

Certain operations described herein include interpreting, receiving,and/or determining one or more values, parameters, inputs, data, orother information (“receiving data”). Operations to receive datainclude, without limitation: receiving data via a user input; receivingdata over a network of any type; reading a data value from a memorylocation in communication with the receiving device; utilizing a defaultvalue as a received data value; estimating, calculating, or deriving adata value based on other information available to the receiving device;and/or updating any of these in response to a later received data value.In certain embodiments, a data value may be received by a firstoperation, and later updated by a second operation, as part of thereceiving a data value. For example, when communications are down,intermittent, or interrupted, a first receiving operation may beperformed, and when communications are restored an updated receivingoperation may be performed.

Certain logical groupings of operations herein, for example methods orprocedures of the current disclosure, are provided to illustrate aspectsof the present disclosure. Operations described herein are schematicallydescribed and/or depicted, and operations may be combined, divided,re-ordered, added, or removed in a manner consistent with the disclosureherein. It is understood that the context of an operational descriptionmay require an ordering for one or more operations, and/or an order forone or more operations may be explicitly disclosed, but the order ofoperations should be understood broadly, where any equivalent groupingof operations to provide an equivalent outcome of operations isspecifically contemplated herein. For example, if a value is used in oneoperational step, the determining of the value may be required beforethat operational step in certain contexts (e.g. where the time delay ofdata for an operation to achieve a certain effect is important), but maynot be required before that operation step in other contexts (e.g. whereusage of the value from a previous execution cycle of the operationswould be sufficient for those purposes). Accordingly, in certainembodiments an order of operations and grouping of operations asdescribed is explicitly contemplated herein, and in certain embodimentsre-ordering, subdivision, and/or different grouping of operations isexplicitly contemplated herein.

The methods and systems described herein may transform physical and/oror intangible items from one state to another. The methods and systemsdescribed herein may also transform data representing physical and/orintangible items from one state to another.

The methods and/or processes described above, and steps thereof, may berealized in hardware, program code, instructions, and/or programs or anycombination of hardware and methods, program code, instructions, and/orprograms suitable for a particular application. The hardware may includea dedicated computing device or specific computing device, a particularaspect or component of a specific computing device, and/or anarrangement of hardware components and/or logical circuits to performone or more of the operations of a method and/or system. The processesmay be realized in one or more microprocessors, microcontrollers,embedded microcontrollers, programmable digital signal processors orother programmable device, along with internal and/or external memory.The processes may also, or instead, be embodied in an applicationspecific integrated circuit, a programmable gate array, programmablearray logic, or any other device or combination of devices that may beconfigured to process electronic signals. It will further be appreciatedthat one or more of the processes may be realized as a computerexecutable code capable of being executed on a machine readable medium.

The computer executable code may be created using a structuredprogramming language such as C, an object oriented programming languagesuch as C++, or any other high-level or low-level programming language(including assembly languages, hardware description languages, anddatabase programming languages and technologies) that may be stored,compiled or interpreted to run on one of the above devices, as well asheterogeneous combinations of processors, processor architectures, orcombinations of different hardware and computer readable instructions,or any other machine capable of executing program instructions.

Thus, in one aspect, each method described above and combinationsthereof may be embodied in computer executable code that, when executingon one or more computing devices, performs the steps thereof. In anotheraspect, the methods may be embodied in systems that perform the stepsthereof, and may be distributed across devices in a number of ways, orall of the functionality may be integrated into a dedicated, standalonedevice or other hardware. In another aspect, the means for performingthe steps associated with the processes described above may include anyof the hardware and/or computer readable instructions described above.All such permutations and combinations are intended to fall within thescope of the present disclosure.

While the disclosure has been disclosed in connection with certainembodiments shown and described in detail, various modifications andimprovements thereon will become readily apparent to those skilled inthe art. Accordingly, the spirit and scope of the present disclosure isnot to be limited by the foregoing examples, but is to be understood inthe broadest sense allowable by law.

1.-595. (canceled)
 596. A method comprising: obtaining a criteria for atrial design study; determining permutations for designs in response tothe criteria; determining permutations for scenarios in response to thecriteria; generating combinations of the permutations for the designsand the permutations for the scenarios; simulating designs correspondingto the generated combinations; and determining performance of thesimulated designs.
 597. The method of claim 596 further comprising:estimating a number of the combinations using the criteria.
 598. Themethod of claim 597 further comprising: in response to the estimatednumber being greater than a threshold, suggesting modifications to thecriteria.
 599. The method of claim 597 further comprising: in responseto the estimated number being less than a threshold, suggestingmodifications to the criteria.
 600. The method of claim 596 furthercomprising: examining the combinations for invalid combinations. 601.The method of claim 596 further comprising: examining the permutationsfor invalid permutations.
 602. The method of claim 596 furthercomprising: predicting the performance of the combinations; and removinga subset of the combinations, prior to simulating the designs, based onthe predicted performance.
 603. The method of claim 602, wherein thepredicting is based on historical data.
 604. The method of claim 596,wherein the combinations are exhaustive for the criteria.
 605. Themethod of claim 596 further comprising: determining optimality from theperformance of the simulated designs.
 606. An apparatus comprising: aspace definition circuit structured to interpret criteria data for atrial design; a design parameter circuit structured to determinepermutations for designs in response to the criteria data; a scenarioparameter circuit structured to determine permutations for scenarios inresponse to the criteria data; a combinations circuit structured togenerate combinations of permutations for designs and permutations forscenarios; and a simulation circuit structured to evaluate a performanceof each combination.
 607. The apparatus of claim 606 further comprising:an estimator circuit configured to estimate number of combinations usingthe criteria.
 608. The apparatus of claim 606 further comprising: avalidity checker circuit configured to examine the combinations forinvalid combinations.
 609. The apparatus of claim 606 furthercomprising: a validity checker circuit configured to examine thepermutations for invalid permutations.
 610. The apparatus of claim 606further comprising: a validity checker circuit configured to: predictthe performance of the combinations; and remove a subset of thecombinations prior to simulating based on the predicted performance.611. The apparatus of claim 610, wherein the performance is predictedbased on historical data.
 612. The apparatus of claim 606, wherein thecombinations of permutations are exhaustive for the criteria.
 613. Theapparatus of claim 606, further comprising an analysis circuitconfigured to determine optimality from the performance.
 614. A methodcomprising: configuring an execution flow for a trial design evaluationusing a configurable interface having at least one node element and atleast one arc element, wherein the execution flow is defined, in part,via the at least one node element and the at least one arc element;executing the trial design evaluation using the execution flow;reconfiguring at least one of the at least one node element or the atleast one arc element in the execution flow; and executing the trialdesign evaluation using the reconfigured execution flow.
 615. The methodof claim 614, further comprising: evaluating historical trial designselections to identify one or more trial design parameters based atleast in part on one or more trial design criteria determined from auser via an interactive interface, wherein executing the trial designevaluation is based at least in part on a quick search data structureand the one or more trial design parameters; generating a substitute forat least some results from the execution of the trial design evaluationbased at least in part on a relationship between the results andsupplemental data; generating a performance surface based at least inpart on a set of trial designs corresponding to the results; evaluatingone or more trial designs based at least in part on the performancesurface; and calculating a score based on normalized score componentvalues corresponding to the results from the execution of the trialdesign evaluation. 616.-696. (canceled)